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Simulation  And  Visualization  Opportunities  In  The  Ship 
Production  And  Maritime  Environment 

Alan  Behning  (V),  Advanced  Marine  Enterprises,  Inc,  .Todd  Cary  (AM) 

NAVSEA,  James  Wittmeyer  (M),  Advanced  Marine  Enterprises,  Inc. 

ABSTRACT 

This  paper  provides  an  introduction  to  the  application  of  commercial  off  the  shelf  (COTS)  and  PC  based 
simulation  and  visualization  software  in  the  ship  production  and  maritime  environment.  It  is  intended  to 
assist  the  shipyard  manager,  production  engineer,  naval  architect  and  marine  engineer  in  identifying 
simulation  and  visualization  opportunities  in  the  areas  of  production,  project  management,  training,  design, 
and  port  evaluation  for  vessel  loading/unloading  times.  The  desired  features  of  simulation  and  visualization 
software  for  maritime  applications  are  discussed,  and  a  sample  listing  of  both  maritime  and  non-maritime 
simulation  efforts  is  provided.  In  addition  to  this  general  discussion,  two  projects  which  utilize  these 
technologies  are  described. 


INTRODUCTION 

Today,  through  the  evolution  of  technology,  simulation 
and  visualization  capabilities  have  been  transferred  from  expensive 
main  frames  and  work  stations  to  affordable  desk  top  computers. 
The  software  applications  themselves  have  also  evolved  from 
specialized  one-of-a-kind  products  to  essentially  commercial-off- 
the-shelf  (COTS)  products.  This  transformation  has  resulted  in  a 
much  broader  expanse  of  application  for  simulation  and 
visualization  technology.  No  longer  are  the  tools  solely  used  by 
large  corporations,  governments,  and  universities  for  complex, 
time  consuming  problems.  Instead  they  are  used  by  companies  of 
all  sizes  for  applications  ranging  from  plant  layout  and  training  to 
analyzing  and  evaluating  ship  systems  and  sub- systems.  The 
results  that  are  being  obtained  through  the  application  of  these 
technologies  include  more  informed  operators,  design  optimization 
options,  and,  of  course,  the  simple  answer  of  whether  or  not  a 
concept  will  work. 

In  order  to  provide  some  insight  as  to  what  is  required  to 
use  these  technologies,  as  well  as  to  provide  more  detailed 
information  on  the  benefits  that  may  be  obtained,  two  projects  are 
discussed  in  detail  in  this  paper.  The  first  project  entails  the  use  of 
simulation  software  to  model  the  mess  line  flow  for  a  ship’s  galley 
while  the  second  project  involves  the  linking  of  visualization 
software  with  scheduling  software.  This  latter  capability  allows  for 
the  3-D  visualization  of  ship  production  schedules,  illustrating  the 
effect  on  ship  assembly  and  erection  processes  of  modifications  to 
that  schedule.  In  addition  to  these  two  projects  a  number  of  other 
potential  applications  for  simulation  and  visualization  techniques  in 
the  shipbuilding  and  design  arena  are  identified. 

SIMULATION 


Simulation  can  be  described  as  a  number  of  things,  yet 
simply  put  it  is  both  a  process  and  a  tool.  It  is  a  process  when  it  is 
used  as  a  method  for  modeling  a  sequence  of  events,  and  it  is  a 
tool  when  that  model  is  then  used  to  produce  results  which  can  be 
analyzed.  This  dichotomy  in  definition  is  also  shown  in  the 
definition  provided  by  The  New  Lexicon  Webster  s  Encyclopedic 
Dictionary  Of  The  English  Language  which  states: 

Simulation:  a  representation  of  a  product,  condition,  or 
process  in  a  different  medium,  e.g.,  computer,  statistical 
chart,  mock-up,  esp.  for  the  purpose  of  analysis.  [1] 

In  his  paper  “Introduction  To  Simulation”,  presented  at 
the  Winter  Simulation  Conference  1995,  Andrew  F.  Seila, 
Professor,  University  of  Georgia,  concurs  with  this  definition  and 
further  indicates  that: 

All  simulations  are  developed  to  determine  system 
performance  under  alternative  designs  or  environments, 
with  the  objective  of  optimally  designing  or  operating 
the  system.  [2] 

In  other  words,  simulation  allows  one  to  experience  and 
analyze  a  product,  condition,  or  process  as  if  it  was  actually 
occurring.  This  capability  is  extremely  beneficial  and  has  caused 
simulation  to  become  a  leading  system  analysis  method. 

Simulation  is  an  excellent  tool  that  can  be  used  to 
analyze  just  about  any  level  of  system  complexity.  The  complexity 
of  the  system  is  limited  only  by  the  person  modeling  the  system, 
the  physical  capacity  of  the  computer,  and  the  software  chosen  for 
a  particular  analysis.  The  system  must  also  be  well  understood  by 
the  modeler  prior  to  being  modeled.  The  analytical  results 
obtained  through  simulation,  and  the  visual  representation  of  the 
model,  provide  an  actual  approximation  of  the  system  and  can 
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carry  credibility  to  the  actual  decision  makers.  In  short,  simulation 
brings  a  sense  of  reality  to  the  analysis  of  a  system.  Simulation 
provides  the  capability  of  analyzing  any  stochastic  system  without 
regard  to  its  structure  or  complexity. 

Types  Of  Simulation  Software 

There  are  basically  four  categories  of  simulation 
software.  These  categories,  and  some  example  products,  are 
identified  below  in  Table  I. 


Classification  Type 

Examples 

General  Purpose  Languages  and 
Simulation  Libraries 

Fortran,  Pascal,  C,  Algol,  etc., 
and  SIMLIB,  SIMTOOLS 

Simulation  Programming  Languages 

GPSS,  SIMSCRIPT 

Interactive  Simulation  Programming 
Systems 

SIGMA,  CAPS/ECSL 

Visual  Interactive  Modeling  Systems 

AutoMod,  ProModel,  Arena, 
Witness,  SIMFACTORY 

Table  I.  Simulation  Software  Classifications  [2] 

As  can  be  seen  by  examining  this  table,  simulation  software 
products  come  in  a  wide  variety  of  packages  with  a  varying 
number  of  features  and  levels  of  difficulty.  Each  of  these 
categories  has  its  pros  and  cons.  As  an  example,  the  ‘Simulation 
Programming  Languages’  category  provides  users  with  a  product 
that  is  a  standardized  simulation  language  from  which  to  make  his 
or  her  models.  While  this  tends  to  provide  the  greatest  amount  of 
flexibility  in  creating  models,  whether  they  be  small  and  simple 
ones  or  large  and  highly  complex,  this  category  also  requires  a  lot 
of  effort  on  the  part  of  users.  With  products  from  this  category  the 
user  not  only  needs  to  know  the  procedures  that  will  define  the 
model,  but  also  needs  to  know  how  to: 

•  Program  these  procedures  in  the  language  of  the  selected 
product; 

•  Create  the  constructs  which  will  allow  information  to  be 
retrieved  from  the  model  as  the  simulation  runs;  and,  if  desired, 

•  How  to  construct  graphical  images  to  visually  portray  the 
model’s  processes  in  action. 

Though  not  as  flexible  as  the  Simulation  Programming 
Languages  category,  the  Visual  Interactive  Modeling  Systems 
category  contains  many  of  the  same  benefits  with  a  shorter 
learning  curve.  At  the  low  end  of  the  spectrum  in  this  category  are 
the  user  friendly ,  canned  products  which  combine  a  simple  to  use 
interface  with  pre-made  modeling  features.  These  products  are 
excellent  tools  with  which  to  model  simple  and  small  processes.  At 
the  other  end  of  this  category,  vendor  specific  proprietary 
simulation  languages  have  been  added  to  the  product  providing 
them  with  the  flexibility  required  to  model  large  and  highly 
complex  processes.  Even  at  this  end  of  the  category,  users  can  still 
be  constrained  by  the  features  of  the  inbred  simulation  language, 
as  well  as  his  or  her  own  limits  in  understanding  that  language. 

The  exact  method  of  simulation  found  throughout  these 
categories  of  products,  is  still  basically  one  of  two  types,  either 


time-independent  models  or  stochastic  processes.  Simulations 
involving  stochastic  processes  represent  the  majority  of  the  models 
analyzed  with  simulation  procedures.  They  can  also  be  further 
subdivided  into  either  discreet  event,  or  continuous  simulation. 

Discrete  Event  Simulation.  Discrete  event  simulation 
is  an  incremental,  or  step  by  step,  process  where  the  simulation 
proceeds  from  one  event  to  the  next.  The  events  can  be  either 
time  or  queue  driven,  and,  either  deterministic  or  stochastic  in 
nature. 

When  the  process  is  time  derived  it  uses  a  fixed  time 
step  such  as  seconds,  minutes,  hours,  days,  etc.,  with  which  to 
advance  the  simulation.  This  method  of  modeling  provides  for  a 
real  life  feel  to  the  visualization  of  the  simulated  process.  Real  life 
in  this  case  refers  to  the  fact  that  the  model  is  advancing  as  if  it 
was  a  real  time  visualization  or  enactment  of  the  process.  In 
queue  driven  or  variable  time  step  simulation  the  time  spans 
between  events  are  not  visually  portrayed.  The  key  word  here  is 
visually  portrayed. 

The  variables  used  in  discrete-event  simulations  models 
are  also  typically  stochastic.  This  allows  the  incorporation  of 
statistical  probability  analysis  into  the  model  providing  for  a  much 
more  accurate  representation  of  the  modeled  events.  The  more 
accurate  and  detailed  these  stochastic  processes  are  made  the  more 
precise  the  simulation  results  will  be. 

Continuous  Simulation.  Unlike  discrete-event 
simulation,  continuous  simulation  is  not  an  incremental  simulation 
process,  but  rather  a  ‘start  to  stop’  process  that  is  primarily 
interested  in  showing  the  beginning  and  end  results  of  the  process 
being  modeled.  The  actual  approach  taken  in  these  models  is  to 
model  the  system  as  a  differential  equation  where  time  is  treated  as 
a  continuous  variable.  The  solution  is  obtained  by  solving  the 
differential  equation.  An  example  is  using  differential  equations  to 
construct  a  predator/prey  simulation  model. 

Simulation  Based  Design 

Although  in  existence  for  a  number  of  years,  Simulation 
Based  Design  (SBD),  is  a  relatively  new  and  up-coming 
technology  that  promises  great  returns.  Part  of  this  popularity  is 
due  to  the  rapid  advancements  in,  and  the  increased  availability  of, 
desk  top  computers.  It  is  a  method,  or  process,  that  allows  for  a 
high  degree  of  concurrent  engineering  between  the  design  process, 
the  simulation  and  analysis  of  the  product,  and  the  design  decisions 
being  made.  In  its  current  computerized  format  it  has  been  applied 
to  a  great  variety  of  problems;  from  evaluating  manufacturing 
systems  to  analyzing  public  services  and  business  processes. 

Some  areas  of  application  for  SBD  in  the  ship 
design/production  arena  are  shown  in  Table  II. 

By  modeling  and  analyzing  process  flows  in  a  proposed 
ship  design  or  manufacturing  process  lane,  problem  areas, 
throughputs,  and  utilization  factors  can  be  identified.  The 
simulation  model  can  then  be  modified  to  remove  the  problem 
and/or  enhance  and  optimize  the  overall  design  of  the  product  or 
process  being  modeled.  With  simulation  these  changes  and 
repeated  analysis  can  be  performed  a  number  of  times  quickly  at 
relatively  low  cost. 
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DESIGN 

-  Space  Allocation  Optimization 

-  Space  Arrangement  Optimization 

-  Special  Evolution  Time  Studies 

-  Equipment  Selection  Optimization 

-  Galley  &  Mess  Line  Flow  Studies 

-  Equipment  Selection  &  Manning 
Requirement  Studies 

-  General  Arrangement  Studies 

-  Special  Evolution  General 
Arrangement  Studies 

-  Identify  Optimum/Correct 
Location  For  Abandon  Ship 
Lifeboat  Stations 

-  Evacuation  Route  Analysis _ 


-  Disembarkation  Route  Analysis 

-  Equipment  Selection/Manning 
Analysis 

PROJECT  MANAGEMENT 

-  Schedule  Development 

-  Queuing  Date  Determination 

-  Planning 

-  Acquisition  Date  Determination 
TRAINING 
PRODUCTION 

-  Shipyard  Production  Lanes 

-  Shipyard  Construction  Planning 
&  Work  Load  Leveling  Aid 

PORT  EVALUATION  FOR 
CARGO  OPERATIONS 


Table  II.  SBD  Applications  In  The  Ship  Design/  Production 
Arena 

Simulation  Software  Recommendation.  In  modeling 
and  analyzing  processes  involving  the  construction  or  design  of  a 
ship,  or  ship  portions  (e.g.  galley  area  design  and  utilization), 
where  the  overall  process  to  be  modeled  consists  of  a  number  of 
smaller  processes,  a  product  from  the  Visual  Interactive  Modeling 
Systems  category  of  Table  I  that  uses  the  Discrete-Event 
Simulation  method  is  recommended.  The  reasons  for  this  are: 

•  Ability  to  model  by  steps/events  or  queues; 

•  Availability  of  software; 

•  Ability  to  perform  “what  if’  analysis  during  the  simulation  run; 
and 

•  Ability  to  subdivide  a  problem  into  distinct,  manageable 
problem  areas. 

Discrete-event  simulation  software  should  have  the 
capability  of  importing  CAD  drawings  into  the  model  as  templates. 
This  capability  provides  users  with  an  added  degree  of  flexibility 
for  using  CAD  developed  drawings  as  background  templates  over 
which  a  model  can  be  constructed,  or  as  background  templates  on 
which  objects  can  be  built.  The  former  capability  prevents  users 
from  having  to  recreate  a  drawing  within  the  simulation  product 
environment,  while  the  latter  option  allows  objects  to  be  created 
and  placed  within  the  model  being  built  that  closely  resemble  their 
actual  CAD  drawings.  These  objects  could  represent  stationary 
background  objects  or  a  specific  type  of  vehicle  within  the  model. 

There  are  currently  a  number  of  software  simulation 
products  available  on  the  commercial  market  that  fall  under  the 
Visual  Interactive  Modeling  Systems  category  identified  in  Table  I. 
All  of  these  products  are  ‘canned’  simulation  packages  in  that  they 
provide  pre-constructed  elements  with  which  to  construct  the 
process  model.  The  simulation  models  are  themselves  created  by 
simply  selecting  the  desired  element,  placing  it  at  the  appropriate 
modeling  environment  location,  identifying  the  characteristics 
associated  with  it,  and  then  linking  it  to  the  other  elements  of  the 
model  to  show  the  process  dependencies.  The  amount  of 
programming  actually  required  is  dependent  on  the  level  of 
complexity  desired  in  the  model. 


In  selecting  a  product  one  should  also  consider  the 
following  factors  in  addition  to  the  basic  features  of  the  product 
and  those  factors  mentioned  above: 

•  A  user  interface  that  provides  the  best  format  for  ease  of  adding 
detail  to  a  model  after  its  initial  construction; 

•  A  user  interface  simulation  language  that  is  easy  to  understand; 

•  Software  capability  to  develop  and  use  sub-routines  in  the 
simulation  code; 

•  Software  that  provides  excellent  graphical  features,  including 
true  3-D  graphics,  and  the  ability  to  create  movies  of  the 
process  being  simulated  for  viewing  on  video  cassette  recording 
machines; 

•  Software  that  provides  the  ability  to  construct  the  model  to  scale 
in  either  U.S.  customary  or  metric  units; 

•  The  availability  of  the  software  for  both  PCs  and  UNIX 
workstations;  and 

•  The  ability  to  model  material  flow  processes,  apply  routing  logic 
to  the  model,  assign  attributes  to  model  elements,  and  apply 
statistical  distributions  to  the  processes  being  modeled. 

Some  examples  of  past  process  flow  simulation 
applications  are  identified  in  Table  III.  These  examples  were  taken 
from  a  wide  variety  of  sources  that  include  product  information 
brochures  and  publications  by  the  American  Society  of  Naval 
Engineers. 

PROCESS  FLOW  SIMULATION 

Due  to  the  ever  increasing  complexity  of  the  ship  design 
process,  where  the  overall  goal  is  to  meet  the  owner’s 
requirements  while  designing  for  affordability,  the  need  for  a  tool 
that  has  the  capability  of  analyzing  and  determining  the 
characteristics  of  discrete  event  shipboard  activities  has  emerged. 
In  an  effort  to  demonstrate  the  utility  of  process  flow  simulation 
software  in  fulfilling  this  need,  a  small  pilot  program  was  initiated 
that  modeled  the  processes  associated  with  personnel  flow  through 
a  ship’s  mess  line. 

The  mess  line  flow  effort  was  approached  in  two  phases. 
The  first  phase  included  the  identification  of  the  mess  line  process 
flow  interactions  that  were  to  be  studied,  and  the  collection  and 
development  of  data  to  represent  these  processes.  The  second 
phase  involved  the  actual  development  and  analysis  of  the  process 
flow  simulation  model. 
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Process  Flow  Simulation  Applications 

Simulation  and  analysis  of  the  LPD  17  starboard  mess  line  flow 

Evaluation  of  proposed  Singapore  Port  changes/expansions 

Use  of  simulation  to  create  a  tool  for  standardizing  the  layout  of 
future  Taco  Bell  restaurants 

Use  of  simulation  to  improve  the  traffic  flow  through  current  Taco 
Bell  restaurants 

Simulation  of  the  production  processes  of  the  Boeing  777 

Simulation  of  the  roll  out  celebration  for  the  Boeing  777 

Simulation  of  a  steel  stockyard  operation  in  connection  with  a  lay¬ 
out  development 

Simulation  of  a  cutting  shop  in  connection  with  the  modernization 
program 

Simulation  of  the  entire  prefabrication  facilities  at  a  Norwegian 
shipyard 

Simulation  of  different  ship  construction  approaches  at  a  German 
shipyard 

Simulation  of  different  steel  fabrication  lines  for  various  customers 

Motorola  and  its  partners  simulated  the  entire  supply  chain  for  the 
manufacturing  and  delivery  of  the  low  earth  orbit  satellite 
communication  system 

Simulation  of  the  John  Hopkins  hospital’s  main  cafeteria  serving 
process  to  both  staff  and  visitors 

Simulation  of  the  LHA  1  Class  cargo  handling  system 

Table  III.  Process  Flow  Simulation  Applications 

The  results  that  would  be  obtained  from  this  model 
would  provide  the  following  information: 

•  The  amount  of  time  needed  to  feed  the  total  crew  and  troop 
complement; 

•  The  flow  rate  of  personnel  passing  through  the  serving  line; 

•  The  number  of  personnel  passing  through  the  serving  line  in 
the  first  21  minutes  (21  minutes  represents  the  allotted  eating 
duration); 

•  The  utilization  factors  of  the  Food  Service  Attendants  (FSAs) 
and  Mess  Specialists  (MSs)  along  the  serving  line,  and  of  the 
FSA  restocking  utensils;  and 

•  The  effects  of  different  mess  deck  seating  variations  on  the  time 
needed  to  serve  the  crew  and  troops. 

As  part  of  the  investigation  undertaken  in  Phase  I, 
commercial  kitchen  standards  were  utilized,  as  well  as  input  from 
Navy  supply  representatives.  This  information  was  used  to  select  a 
menu  to  model,  as  well  as  to  help  identify  the  serving  sizes, 
equipment  capacities,  process  times,  and  personnel  interactions 
associated  with  the  utilization  of  the  mess  line.  Another  Phase  I 
decision  item  was  the  extent  to  which  the  galley  mess  line  area 
would  be  modeled.  Because  the  task  was  a  small  pilot  program,  it 
was  decided  that  an  application  of  limited  scope  would  be  enough 
to  demonstrate  the  utility  of  using  a  process  flow  simulation  tool  in 
helping  to  design  and  analyze  food  service  operations.  As  a  result, 


the  actual  scope  of  the  process  flow  simulation  model  was  reduced 
to  modeling  only  the  starboard  serving  line,  half  the  ship’s 
personnel,  and  half  the  seating  capacity.  In  addition  to  the  ship’s 
personnel  utilizing  the  serving  line,  the  mess  line  support  personnel 
were  also  modeled  since  they  have  a  direct  effect  on  the  proper 
operation  of  the  serving  line.  Other  features  that  have  been 
incorporated  into  the  model  include: 

•  The  traffic  flow  of  the  crew  and  troops  during  meal  time; 

•  The  menu  being  served  and  the  menu  selection  distribution  of 
the  crew  and  troops; 

•  The  actions  of  the  crew  members  in  the  serving  line  and  of  the 
personnel  supporting  the  serving  line,  but  not  those  in  the 
galley;  and 

•  The  movement  of  the  crew  and  troops  to  either  of  the  two 
entrances  into  the  Mess  Deck. 

The  following  sub-section  provides  a  detailed 
description  of  the  assumptions  and  methods  used  in  creating  the 
simulation  model.  The  results  that  were  obtained  from  this  model 
are  discussed  in  the  sub-section  titled  Simulation  Run  Results. 

Assumptions  and  Constraints 

In  addition  to  the  top  level  model  behavior  decisions 
already  mentioned,  a  number  of  assumptions  and  decisions  were 
made  with  regards  to  the  technical  accuracy  of  the  simulation  prior 
to  developing  the  model.  These  covered  such  areas  as  the  menu 
being  modeled,  food  item  locations,  serving  line  processing 
stations,  resources  required  for  serving  the  meal,  the  characteristics 
of  these  resources,  and  personnel  characteristics.  The  following 
subsections  identify  and  document  these  decisions,  and  provide  the 
reasoning  behind  them. 

Serving  Line  Layout.  The  starboard  mess  line  was 
modeled  based  on  a  CAD2  drawing  provided  to  the  project  team. 
This  drawing  served  as  the  template  on  which  the  simulation 
model  is  built.  As  a  result  the  simulation  model  was  created  to 
scale  with  the  3-D  elements  displayed  located  above  the  actual 
footprints  of  the  objects  they  represented. 

Crew  Size.  The  crew  consisted  of  both  the  ship’s 
enlisted  crew  (429)  as  well  as  the  maximum  number  of  embarked 
troops  (597)  that  the  ship  was  designed  for.  With  only  the 
starboard  mess  line  modeled  in  the  simulation,  the  number  to  be 
served  by  this  mess  line  is  513,  or  half  of  the  total  complement. 

Mess  Deck  Capacity.  The  mess  deck  was  also 
modeled  as  half  of  that  identified  in  the  ship’s  drawings.  As  a 
result  the  baseline  simulation  model  contains  only  84  seats. 

Mess  Specialist  and  Food  Service  Attendant 
Stations  and  Duties.  The  mess  line  support  personnel  for  which 
utilization  rates  were  determined  are  identified  in  Table  IV  along 
with  their  primary  duties  and  location. 
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Crew  Member 
Identification 

Primary  Duties 

Primary  Location 

FSA#1 

Hotwell  Server 

Galley  behind  hotwells  2,  3, 4 

FSA#2 

Hotwell  Server 

Galley  behind  hotwells  5,  6,  7 

FSA#3 

Hotwell  Bin  Reloader 

Galley 

FSA#4 

Utensil  Bin  Reloader 

Sculleiy 

MS#1 

Grill  Operator 

Galley  behind  grill 

MS#2 

Grill  Operator 

Galley  behind  grill 

Table  IV.  Serving  Line  Manning  Requirements 

Since  the  grill  is  used  only  to  cook  chicken  breasts  for 
dispensing  from  the  hotwell,  only  one  cook  is  required  for  use 
during  the  simulation  run.  As  a  result  MS#1  is  not  utilized  during 
this  study. 

Traffic  Flow.  An  equally  important  element  of  the 
simulation  model  is  the  traffic  flow  of  the  troops  and  crew 
members  in  the  serving  line,  as  well  as  the  interaction  between 
them  and  the  crew  members  on  duty  in  the  mess  area.  To  account 
for  these  actions  a  number  of  assumptions  were  made.  Because 
one  of  the  basic  goals  of  this  project  was  to  determine  the 
throughput  of  the  mess  line,  it  was  decided  early  on  that  the 
simulation  model  would  not  take  into  account  the  staggered  arrival 
process  of  personnel  for  meals  as  would  actually  occur  aboard 
ship.  Specifically,  early  meal  for  watch  reliefs,  head  of  the  line 
privileges  for  first  class,  and  late  arrival  of  off-coming  watch 
standers  were  not  modeled.  The  model  also  assumed  a  steady  flow 
of  personnel  from  the  starting  point  after  the  simulation  run  began 
for  a  worst  case  scenario.  The  starting  point  is  the  starboard 
vestibule  forward  of  the  bulkhead  at  frame  47V£,  which  contains 
the  starboard  ladder  well.  These  assumptions,  in  addition  to 
providing  an  easy  method  for  determining  the  throughput  of  the 
mess  line,  and  the  steady  flow  rate,  also  helped  to  simplify  the 
complexity  of  the  model  for  this  pilot  study. 

In  order  to  accommodate  the  interaction  of  the  model 
elements  during  any  given  simulation  run,  a  number  of  other 
assumptions  regarding  the  traffic  flow  were  also  made.  These 
assumptions  and  the  factors  that  are  applied  in  the  simulation 
model  are  identified  below. 

•  Width  of  95  percentile  man  =  0.56  m  (1.8  ft).  [3] 

•  Personnel  walking  speed  =1.16  m/sec  (3.81  ft/sec).  [3] 

•  Minimum  spacing  of  personnel  in  the  mess  line  =  0.8  m  (2.7  ft) 
(distance  from  leading  edge  of  one  person  to  the  leading  edge  of 
the  next). 

•  Mess  line  path  width  =  0.6  m  (2  ft). 

•  Personnel  will  stay  in  the  mess  line  until  entering  the  mess 
deck. 

•  60%  of  the  crew  will  use  the  starboard  mess  deck  entrance,  and 
40%  will  use  the  centerline  entrance 

•  Maximum  capacity  in  the  mess  deck  =  84  personnel 

•  Each  troop  or  crew  member  will  use  the  mess  deck  for 
approximately  21  minutes  (currently  set  at  constant  value). 

•  The  starboard  serving  line  began  at  the  starboard  water  tight 
door  at  frame  471/2  from  the  inclined  ladder  vestibule  and 
proceed  aft. 


•  The  line,  as  it  moves  aft,  is  routed  along  the  outboard  bulkhead 
until  frame  60  where  it  then  turns  inboard  and  forward  to  pass 
along  the  serving  line. 

•  If  the  scullery  FSA  is  reloading  a  utensil  dispenser,  then  the 
crew  in  the  mess  line  will  not  be  able  to  select  that  type  of 
utensil  until  the  FSA  is  finished  reloading  the  dispenser 

•  The  hotwell  server  assists  the  hotwell  reloader  for  12  seconds 
when  one  of  his  or  her  hotwells  is  being  reloaded;  the  first 
hotwell  server  also  assists  the  reloader  with  the  soup  hotwell. 

•  When  the  hotwell  server  is  assisting  the  hotwell  reloader,  the 
mess  line  is  unable  to  select  food  from  that  station  until  the 
hotwell  server  is  done. 

•  A  Mess  Deck  Master  At  Arms  will  be  positioned  at  the  end  of 
the  serving  line  to  control  access  to  the  mess  deck. 

The  reason  the  crew  member  width  was  based  on  the 
width  of  the  95  percentile  man  is  because  it  provides  an  accepted 
figure  that  represents  the  higher  end  of  the  range  that  could 
possibly  be  experienced  aboard  ship.  Except  for  helping  to  identify 
the  required  width  of  the  mess  line  traffic  path,  this  figure  has  no 
other  impact  on  the  simulation  model  or  its  results. 

The  mess  line  flow  path  was  modeled  in  accordance 
with  the  drawings,  and  as  indicated  above.  In  addition,  fourteen 
process  or  action  stations  were  placed  along  its  length.  These 
stations  identify  locations  where  actions  are  performed  by  the  crew 
member  traveling  along  the  path.  As  an  example,  at  Station  2,  the 
menu  board,  each  crew  member  pauses  to  read  the  menu.  The 
length  of  the  pause  is  based  on  a  triangular  distribution  between  0 
and  5  seconds  with  the  mode  at  2  seconds.  A  description  of  each 
station  is  provided  in  Table  V. 


Station 

Description 

Station 

Description 

1 

Mess  Line  Entrance 

8 

Hotwell  1 

2 

Menu  Board 

9 

Hotwell  2,  3,  4 

3 

Tray  Pick  Up  Point 

10 

Hotwell  5,  6,  7 

4 

Plate  Pick  Up  Point 

11 

Dessert  Pick  Up  Point 

5 

(For  future  use) 

12 

Bread  Pick  Up  Point 

6 

(For  future  use) 

13 

Starboard  Mess  Deck 

Entrance 

7 

Bowl  Pick  Up  Point 

14 

Centerline  Mess  Deck 

Entrance 

Table  V.  Mess  Line  Routing  Sequence 

As  indicated  in  Table  V,  the  trays,  plates,  and  bowls 
were  picked  up  by  the  person  as  he  or  she  passed  the  appropriate 
station.  Crew  members  were  not  expected  to  pick  up  utensils 
unless  they  used  it  later  for  the  food  they  were  selecting.  In  other 
words,  unless  the  crew  member  wanted  soup,  or  their  vegetables  in 
a  bowl,  they  did  not  pick  up  a  bowl  when  they  reached  Station  7. 
If  they  wanted  both,  they  selected  two  bowls. 

Only  three  other  items,  in  addition  to  the  utensils,  were 
modeled  as  being  self  served  by  the  personnel  as  they  passed 
through  the  line.  These  items  were  the  soup,  dessert,  and  bread 
menu  items. 
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The  FSA  associated  with  the  scullery  work  was  modeled 
as  following  a  path  that  primarily  consisted  of  a  straight  route  from 
the  scullery  out  the  centerline  entrance  of  the  mess  deck,  and  then 
down  the  starboard  passageway  to  the  tray  dispensers  and  into  the 
galley.  This  path  was  used  whenever  the  FSA  was  required  to 
restock  the  trays,  dishes,  or  bowls  in  the  starboard  serving  line,  and 
also  for  the  return  trip  to  the  scullery.  It  was  assumed  that  both  the 
scullery  FSA  and  the  crew  members  in  the  mess  line  avoided  each 
other  as  they  passed,  so  there  were  not  any  delays  in  the  process 
flow  of  either  entity  being  modeled  due  to  congestion. 

Menu.  A  dinner  menu  representative  of  an  actual 
dinner  that  might  be  served  aboard  ship  was  chosen  for  simulation. 
This  menu  was  selected  from  the  NAYSUP  Pub.  421,  Food 
Service  Operations,  January  1994  [4],  and  is  identified  in  Table  VI 
along  with  the  specific  hotwell  or  other  designated  area  of  the 
serving  line  from  which  the  indicated  menu  item  is  served.  Note: 
The  extended  serving  line  is  not  modeled  and  therefore  the  salad 
and  beverage  area  are  not  included  in  the  logics  or  graphical 
representation  of  the  starboard  serving  line. 


Location 

Menu  Item 

Hotwell  1 

Pepper  Pot  Soup 

Hotwell  2 

Grilled  Chicken  Fillet 

Hotwell  3 

Tomato  Meat  Loaf 

Forward  Half  Hotwell  4 

Chicken  Gravy 

Rear  Half  Hotwell  4 

Tomato  Sauce 

Hotwell  5 

Au  Gratin  Potatoes 

Hotwell  6 

Steamed  Rice 

Forward  Half  Hotwell  7 

Seasoned  Mixed  Vegetables 

Rear  Half  Hotwell  7 

Steamed  Zucchini 

Cold  Food  Counter 

Fruit  &  Dessert  Bar 

Cold  Food  Counter 

Hot  Pan  Rolls 

Extended  Serving  Line 

Garden  Vegetable  Salad 

Serving  Size.  The  next  step  in  the  development  of  the 
model  consisted  of  determining  the  serving  size  for  each  item  and 
the  maximum  amount  of  servings  that  would  be  present  in  the 
serving  area  (in  most  cases  the  hotwell). 

The  maximum  number  of  servings  that  were  allowed  in 
the  simulation  were  dependent  on  the  type  of  serving  container 
being  used.  Except  for  the  dessert  and  bread  items,  all  items  were 
modeled  as  being  served  from  a  hotwell.  The  model  included  two 
different  types  of  hotwell  pan.  The  nominal  size  and  fluid  ounce 
capacities  of  these  two  types  were  identified  in  the  book  titled 
Commercial  Kitchens  [5],  and  are:  12”  x  20”  x  2  1/2”  for  240  oz 
capacity,  and  12”  x  20”  x  4”  for  464  oz  capacity. 

The  serving  capacity  of  each  hotwell  was  dependent  not 
only  on  the  size  of  the  individual  hotwell,  but  also  on  the  menu 
item  being  served  from  it.  The  serving  size  of  the  menu  item,  the 
hotwell  pan  size  it  was  in,  and  the  maximum  number  of  servings 
contained  by  the  hotwell  is  identified  in  Table  YII  for  each  item. 


Menu  Item 

Serving 

Size 

Hotwell 

Capacity  (oz) 

Servings/ 

Hotwell 

Pepper  Pot  Soup 

8  oz 

464 

58  servings 

Grilled  Chicken  Fillet 

15.25  sq  in 

240  or 

240  sq  in  area 

15  pieces/layer 
or  48  servings 

Tomato  Meat  Loaf 

5  oz 

240 

48  servings 

Chicken  Gravy 

2  oz 

232 

116  servings 

Tomato  Sauce 

2  oz 

232 

116  servings 

Au  Gratin  Potatoes 

6  oz 

464 

77  servings 

Steamed  Rice 

3  oz 

464 

154  servings 

Seasoned  Mixed  Vegetables 

5  oz 

240 

48  servings 

Steamed  Zucchini 

5  oz 

240 

48  servings 

Fruit  &  Dessert  Bar 

N/A 

N/A 

N/A 

Hot  Pan  Rolls 

N/A 

N/A 

N/A 

Garden  Vegetable  Salad 

N/A 

N/A 

N/A 

Table  VII.  Menu  Item  Serving  Size  and  Hotwell  Capacity 


Table  VI.  Menu  Item  Locations 


Food  Selection.  In  addition  to  selecting  the  menu  that 
would  be  modeled,  it  was  also  determined  that  an  appropriate 
distribution  would  need  to  be  developed  that  would  reflect  the  food 
selection  distribution  of  the  troops  and  crew.  The  meal  selection 
distribution  follows: 


•  40%  Soup 

•  45%  Chicken 

•  45%  Meat  Loaf 

•  40%  Au  Gratin  Potatoes 

•  40%  Rice 


•  40%  Seasoned  Mixed 
Vegetables 

•  40%  Steamed  Zucchini 

•  50%  Dessert 

•  50%  Bread 


As  a  result  of  this  distribution  10%  of  the  crew  will  not 
select  either  entree,  20%  of  the  crew  will  not  select  either  starch 
item,  and  20%  of  the  crew  will  not  select  either  vegetable  item. 
This  distribution  also  allows  for  a  0.4  %  chance  that  a  crew 
member  will  not  select  an  entree,  starch,  nor  a  vegetable;  if  this 
occurs  soup  and  bread  will  be  selected  as  default. 


For  the  pilot  program,  the  fruit,  dessert,  and  hot  rolls 
were  modeled  as  being  unlimited  in  quantity,  and  therefore  did  not 
require  tracking  or  restocking.  The  salad  bar  is  not  included 
because  it  was  decided  at  the  onset  of  this  project  that  the  salad  bar 
would  be  located  in  the  mess  deck,  and  that  the  mess  deck  would 
not  be  modeled  in  any  detail. 

In  working  these  elements  into  the  logic  of  the 
simulation  model,  it  was  assumed  that,  except  for  the  soup,  all 
hotwell  items  would  be  served  by  one  of  the  two  FSAs  behind  the 
hotwell  serving  area.  It  was  also  determined  that  at  various  times 
throughout  the  simulation  any  one  of  these  hotwells  might  require 
restocking.  This  can  be  verified  by  simply  comparing  the  hotwell 
serving  sizes  indicated  in  Table  VII  to  the  crew  and  troop  size 
being  modeled  (i.e.  half  the  ship’s  crew  and  troop  complement,  or 
approximately  513  crew  members).  As  a  result,  a  hotwell 
restocking  process  was  incorporated  into  the  model.  This 
restocking  process  involves  a  FSA  working  in  the  galley,  and 
requires  him  or  her  to  manually  replace  the  hotwell. 

The  actual  restocking  process  is  initiated  when  the 
quantity  contained  within  a  hotwell  reaches  a  specific  level.  For 
this  model  it  was  determined  that  this  level  would  be  at  10%  of  the 
initial  quantity.  This  assumption  is  in  close  accordance  with  the 
process  that  actually  occurs  aboard  ship,  where  the  pans  are 
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usually  never  completely  empty  before  a  replacement  pan  is  placed 
in  the  serving  line.  It  was  also  decided  that  any  left  over  servings 
from  the  old  pan  would  be  added  to  the  amount  contained  in  the 
new  pan  when  the  restocking  process  occurred. 

In  addition  to  these  assumptions,  it  was  also  decided  that 
the  initial  amount  in  an  original  or  replacement  hotwell  would  be 
either  90%  or  75%  of  the  maximum  capacity  depending  on  the 
type  of  item  in  the  hotwell.  For  liquids  75%  was  used,  while  90% 
was  used  for  solids.  This  margin  in  hotwell  capacity  was  intended 
to:  prevent  items  from  falling  or  sloshing  out  of  the  hotwell  pan  as 
it  or  the  ship  moved;  and  prevent  spills  from  occurring  due  to  the 
addition  of  the  leftovers  to  the  hotwell  replacement  pan. 

The  serving  amounts  identified  in  Table  YII  were 
therefore  adjusted.  It  was  also  decided  that  the  replacement 
amount  for  a  hotwell  would  be  equal  to  its  initial  amount  of 
servings.  Although  these  factors  are  identical,  in  the  simulation 
model’s  code  they  are  independent  variables  and  may  be  changed 
by  the  user  when  desired. 

Utensil.  The  utensil  dispensers  modeled  in  this 
simulation  are  based  on  the  selected  ship  design  drawing  obtained 
by  the  project  team.  In  that  design  drawing  it  was  identified  that 
the  tray,  plate,  and  bowl  dispensers  would  be  located  along  the 
mess  line,  and  the  silverware  would  be  obtained  from  above  the 
tray  dispensers.  It  was  also  specified  that  the  trays  would  be  of  the 
non- segmented  or  flat  type,  and  that  the  silverware  would  be 
obtained  when  a  tray  was.  Because  of  this  the  silverware  and  trays 
are  modeled  and  tracked  as  one  unit. 

In  working  these  elements  into  the  logic  of  the 
simulation  model,  it  was  also  assumed  that  40%  of  the  crew  would 
want  to  use  a  bowl  for  something  other  than  soup.  In  this  model 
this  other  use  was  to  hold  vegetables.  Another  area  of  concern  that 
was  addressed  by  the  model  was  the  restocking  of  these  utensil 
dispensers.  Since  none  of  the  dispensers  have  an  initial  quantity 
large  enough  to  support  the  troop  and  crew  size  being  modeled  the 
restocking  process  for  the  dispensers  was  also  incorporated  into  the 
model.  This  restocking  process  involves  a  FSA  working  in  the 
scullery,  and  requires  him  or  her  to  manually  carry  the  restock  load 
from  the  scullery  to  the  appropriate  dispenser.  Mobile  carts  cannot 
be  used  because  the  scullery  has  a  22.9  cm  (9  in)  sill  around  it  to 
prevent  water  from  entering  the  mess  area. 

The  actual  restocking  process  is  initiated  when  the 
quantity  contained  within  a  dispenser  reaches  a  specific  level.  This 
level  along  with  the  initial  amount  and  refill  size  for  each  dispenser 
are  identified  in  Table  VIII.  Note:  Refill  size  indicates  load  size 
carried  by  the  scullery  FSA. 


Utensil  Name 

Initial  Amount 

Refill  Point 

Refill  Size 

Tray  Dispenser  1 

150 

50 

25 

Tray  Dispenser  2 

150 

50 

25 

Plate  Dispenser  1 

72 

24 

12 

Plate  Dispenser  2 

72 

24 

12 

Bowl  Dispenser  1 

36 

12 

12 

Bowl  Dispenser  2 

36 

12 

12 

Bowl  Dispenser  3 

36 

12 

12 

Table  VIII.  Utensil  Dispenser  Refill  Information 


Once  the  restocking  process  is  initiated  for  a  utensil 
dispenser,  the  scullery  FSA  will  make  as  many  trips  as  required  in 
order  to  bring  the  utensil  dispenser’s  amount  equal  to,  or  above,  its 
refill  point. 

Process  Time  Assumptions.  In  order  to  create  a 
simulation  model  that  reflected  the  actual  mess  line  process  as 
accurately  as  possible,  process  times  were  required  to  be  associated 
with  each  specific  process  being  modeled  in  the  simulation. 
Because  of  the  inherent  variability  of  the  time  associated  with  any 
of  these  processes,  distributions  were  also  attached  to  some  of 
them  in  an  attempt  to  more  accurately  reflect  what  would  occur  as 
the  process  is  repeated  throughout  the  duration  of  the  simulation. 
Unfortunately,  due  to  the  inability  to  conduct  time  studies  on 
which  to  base  these  distributions,  few  of  the  process  time  durations 
used  are  statistically  based.  As  a  result  assumptions  were  made 
regarding  the  time  required  for  crew  members  to  perform  their 
duties  and  conduct  the  modeled  tasks.  The  times  associated  with 
the  FSAs  and  MSs  performing  their  tasks  are  identified  in  Table 
IX.  The  soup,  dessert,  and  bread  are  self  served,  and  MS#1  is  not 
modeled. 


Serving  Time  (FSA#1  &  FSA#2) 

Hotwell  Bin  Refill  Time  (FSA#3) 

Chicken  =  5  sec 

Hotwell  Reload  Time  =  30  sec 

Meat  Loaf  =  5  sec 

Utensil  Bin  Refill  Time  (FSA#4) 

Chicken  Gravy  =  5  sec 

Scullery  load  pick  up  time  =  5  sec 

Tomato  Sauce  =  5  sec 

Scullery  load  drop  off  time  =  5  sec 

Au  Gratin  Potato  =  5  sec 

Chicken  Prep  Time  (MS#2) 

Rice  =  5  sec 

Grill  time  =  uniform  10  i  1  min 

Seasoned  Mixed  Vegetables  =  5  sec 

for  43  chicken  breasts 

Steamed  Zucchini  =  5  sec 

Placement  in  hotwell  =  uniform 

Hotwell  Reload  Assist  Time  =  12  sec 

5.75  +  1  min  for  43  chicken  breasts 

Table  IX.  Resource  Utilization  Times 

The  processes  for  which  time  lengths  are  associated 
with  the  personnel  transiting  the  serving  line  are  identified  below. 

•  Menu  read:  triangular  distribution  0,  2,  5  seconds. 

•  Tray  pickup:  constant  distribution  2  seconds. 

•  Plate  pickup:  constant  distribution  2  seconds. 

•  Bowl  pickup:  constant  distribution  2  seconds. 

•  Desert  pickup:  constant  distribution  2  seconds. 

•  Bread  pickup:  constant  distribution  4  seconds. 

•  Mess  deck  use:  constant  distribution  21  minutes. 

The  mess  deck  utilization  of  21  minutes  is  based  on  the  standard 
design  factor  of  18  minutes  of  use  per  person  with  an  additional  3 
minutes  to  account  for  the  time  taken  to  get  his  or  her  drink  and 
salad,  find  a  seat,  and  clear  the  area  after  finishing  eating. 

Graphics 

In  addition  to  creating  the  logic  for  the  simulation 
model,  3-D  graphical  images  were  also  created  so  that  the  actual 
process  flow  of  the  starboard  mess  line  could  be  visualized.  These 
graphical  images,  created  within  the  simulation  software  product 
AutoMod,  display  the  changing  status  of  the  model  during  the 
simulation  run.  The  frequency  at  which  these  graphical  images 
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are  updated  can  be  specified  by  the  user,  but  by  default  is  every  1 
second  of  simulated  time.  These  3-D  images  represent  the 
bulkheads  and  equipment  that  are  pertinent  to  the  portion  of  the 
serving  line  mess  area  being  simulated.  The  equipment  is 
approximately  equal  to  its  real  life  size,  and  is  positioned  as 
indicated  on  the  CAD2  drawing.  The  primary  use  of  the 
visualization  capabilities  of  these  types  of  simulation  projects  is  to 
visually  verify  the  accuracy  of  the  process  being  modeled,  and  to 
visually  convey  the  process  being  simulated  to  someone  unfamiliar 
with  it.  Sample  screen  prints  of  these  images  are  shown  in  Figures 
land  2. 


Figure  1.  Serving  Line  Overlaid  On  CAD  Drawing 


Figure  2.  Starboard  Serving  Line  In  Use 
Simulation  Run  Results 

Prior  to  discussing  the  results  of  the  simulation  analysis 
of  the  selected  ship’s  starboard  mess  line  it  should  be  emphasized 
that  the  results  obtained  are  based  on  the  assumptions  and 
conditions  modeled.  Although  these  assumptions  and  conditions 
were  judged  to  be  reasonable  they  were  not  validated.  Therefore 
until  validated  data  is  obtained,  the  results  and  conclusions  drawn 
from  this  analysis  are  only  applicable  to  this  model. 

Using  the  simulation  software,  the  ship’s  starboard  crew 
mess  line  was  modeled  in  accordance  with  the  information  and 
assumptions  presented  in  this  paper.  Due  to  the  deterministic 
nature  of  these  assumptions  (i.e.  all  but  two  time  delays  were 
constant  numbers),  only  one  simulation  run  was  performed  for 
data  collection.  The  primary  reason  for  this  is  that  deterministic 
models  show  no  variance  between  individual  runs;  the  event 
sequencing,  lengths,  and  interactions  are  by  definition 
predetermined.  Except  for  the  mess  cook  grilling  the  chicken  to 
refill  the  chicken  hotwell,  and  each  crew  member  pausing  at  the 
menu  board  in  order  to  read  it,  the  model  developed  for  the  ship’s 


starboard  crew  mess  line  was  deterministic.  This  classification  was 
quantified  during  the  model  testing  stage  when  a  number  of  runs, 
utilizing  various  starting  points  on  the  random  number  stream,  as 
well  as  a  different  type  of  random  number  stream,  were  made  and 
analyzed.  The  results  of  each  test  run  were  identical,  i.e.,  the 
overall  time  length  for  serving  the  crew  and  troops  did  not  change 
between  runs. 

The  primary  reason  for  the  deterministic  nature  of  the 
assumptions  used  in  this  model  is  due  to  the  unavailability  of  data 
on  which  to  accurately  base  and  select  the  form  of  the  statistical 
distributions.  Modifications  however,  can  be  made  to  the  model 
when  this  data  becomes  available,  thereby  implementing  the 
statistical  distributions  and  obtaining  a  stochastic  process. 

In  addition  to  simulating  the  use  of  the  starboard  mess 
line  for  a  half  mess  deck  capacity  of  84  seats,  eight  other 
simulations  of  increasing  mess  deck  capacity  were  also  made.  Each 
of  these  runs  was  performed  under  the  exact  same  constraints  and 
conditions  as  the  original  run  except  for  the  factor  identifying  the 
mess  deck  capacity.  This  factor  was  increased  in  increments  of 
five,  until  a  capacity  of  119  seats  was  reached,  and  then  set  at 
infinite.  The  overall  objective  of  this  analysis  was  to  determine  the 
effect  of  increasing  the  number  of  seats  in  the  mess  deck  on  the 
crew  feeding  time,  as  well  as  the  utilization  rates  of  the  personnel 
supporting  the  mess  line.  The  final  run  at  infinite  seating  capacity 
was  performed  in  order  to  evaluate  the  true  efficiency  of  the 
serving  line  without  any  seating  constraints  being  imposed  upon  it. 
Specifically  the  mess  deck  wait  delay  constraint,  symbolizing  the 
Mess  Deck  Master  At  Arms  control  of  the  mess  deck  access  when 
all  mess  deck  seats  are  occupied,  was  negated. 

Simulation  Run  Time.  The  total  serving  and  messing 
time  associated  with  each  run  is  identified  in  Table  X,  along  with 
the  maximum  duration  spent  waiting  by  any  one  crew  member 
during  the  messing  process.  The  total  serving  and  messing  time 
represents  the  amount  of  time  required  for  all  513  troop  and  crew 
members  to  process  through  the  starboard  serving  line  and  eat  their 
meals  in  the  mess  deck.  The  mess  deck  wait  process  symbolizes 
the  interaction  and  effect  of  the  Mess  Deck  Master  At  Arms  on  the 
mess  line  flow  as  he  or  she  controls  access  to  the  mess  deck  when 
all  seats  are  occupied.  The  maximum  mess  deck  wait  duration 
times  displayed  in  Table  X  identify  the  longest  time  spent  by  any 
one  crew  member  waiting  to  enter  the  mess  deck.  The  specific 
crew  member  that  had  to  wait  is  identified  by  Crew  ID  Number. 
The  Crew  ID  Number  represents  the  identity  of  the  troop  or  crew 
member  being  processed  through  the  simulation,  i.e.  Crew  ID 
Number  1  represents  the  first  person  in  line,  while  Crew  ID 
Number  215  represents  the  215th  person  in  line.  Note:  The  times 
in  Table  X  have  been  rounded  off  to  the  nearest  second. 
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Half  Mess 

Deck  Capacity 

Process 

Total  Serving  and 
Messing  Time 
(hrs:min:sec) 

Information 

Maximum  Mess  Deck 

Wait  Duration 

(min:  sec) 

Crew 

ID# 

84 

2:31:37 

6:18 

85 

89 

2:28:44 

5:26 

90 

94 

2:27:43 

4:25 

95 

99 

2:26:41 

3:40 

100 

104 

2:25:53 

2:36 

105 

109 

2:25:20 

1:43 

110 

114 

2:23:36 

0:52 

115 

119 

2:24:11 

0:05 

145 

Infinite 

2:24:11 

0:00 

N/A 

Table  X.  Process  Information 

As  can  be  seen  by  examining  Table  X,  and  as  would  be 
expected,  the  influence  of  the  mess  deck  seating  on  the  overall 
mess  line  performance  decreases  as  the  seating  capacity  of  the 
mess  deck  increases.  In  fact  at  1 19  seats  the  maximum  mess  deck 
wait  delay  experienced  by  any  crew  member  is  only  five  seconds,  a 
negligible  amount. 

A  similar  conclusion  might  also  be  drawn  from  examining  the 
Total  Serving  and  Messing  Times,  presented  in  Table  X,  for  the 
nine  conditions  modeled.  But  as  can  be  seen  in  Table  X,  the 
process  flow  time  decay  rate  does  not  produce  a  smooth  transition 
between  runs  as  might  be  expected.  The  dip  in  the  decay  rate, 
shown  for  a  half  mess  deck  seating  capacity  of  114  seats,  indicates 
that  the  interaction  between  the  mess  deck  seating  capacity  and  the 
processes  occurring  in  the  serving  line  is  the  most  efficient  at  a  half 
mess  deck  seating  capacity  of  1 14  seats. 

Serving  Line  Throughput.  Another  goal  of  this 
project  was  to  determine  the  number  of  personnel  passing  through 
the  serving  line  (i.e.  completing  all  processes  through  station 
number  12)  in  the  first  twenty-one  minutes.  This  time  span, 
which  equals  the  time  spent  by  a  troop  or  crew  member  using  the 
mess  deck,  was  examined  in  order  to  obtain  a  throughput  that  was 
reflective  of  the  serving  line  and  its  inherent  characteristics,  and 
not  of  the  serving  line  plus  the  constraints  imposed  upon  it  by  the 
seating  capacity  of  the  mess  deck.  The  results  are  identified  in 
Table  XI. 


Half  Mess  Deck  Capacity 

Number  Served 

84 

85 

89 

90 

94 

95 

99 

100 

104 

105 

109 

110 

114 

114 

119 

114 

Infinite 

114 

Table  XI.  Number  Of  Personnel  Served  In  The  First  21 
Minutes 


As  can  be  seen  by  examining  Table  XI,  the  maximum 
serving  line  throughput  for  the  first  twenty-one  minutes  of 
simulation  run  time  is  114  crew  members.  Before  identifying 
exactly  when  this  point  is  reached  though,  some  explanation  of  the 
data  presented  needs  to  be  made.  The  serving  line  throughput,  as 
shown  in  Table  XI,  is  one  person  greater  than  the  mess  deck 
capacity  for  capacities  of  109  people  and  below.  The  reason  for 
this  is  that  the  delay  imposed  by  the  Mess  Deck  Master  At  Arms 
when  the  mess  deck  is  full  is  imposed  immediately  after  a  crew 
member  has  passed  through  the  serving  line  (i.e.  finished 
processing  through  station  number  12).  Asa  result,  although  crew 
member  number  85,  using  a  mess  deck  capacity  of  84  as  an 
example,  passes  through  the  serving  line  in  under  twenty-one 
minutes,  he  or  she  has  to  wait  for  a  certain  amount  of  time  prior  to 
proceeding  into  the  mess  deck.  As  previously  mentioned  this  wait 
signifies  the  amount  of  time  required  before  a  seat  opens  for  him 
or  her  to  use.  Because  this  wait  is  imposed  in  the  physical  location 
of  the  last  station  (a  location  where  a  food  service  process  occurs), 
the  serving  line  throughput  halts  until  this  person  is  able  to  proceed 
into  the  mess  deck.  Using  this  as  the  basis  of  the  interaction  that  is 
occurring  in  the  simulation  model  at  the  end  of  the  serving  line,  it 
can  be  deduced  that  the  serving  line  throughput  reaches  a 
maximum  at  a  mess  deck  seating  capacity  of  1 13  seats. 

Support  Personnel  Utilization.  Identification  of  the 
utilization  rate  for  the  mess  line  support  personnel  was  another 
important  goal  of  this  project.  The  determination  of  the  utilization 
rates  not  only  helps  to  better  understand  the  interactions  being 
simulated,  but  also  provides  information  related  to  manning 
reduction  opportunities.  The  utilization  rates  of  all  of  the  support 
personnel  used  in  this  model  are  identified  in  Table  XII.  The 
location  and  duties  of  these  support  personnel  are  defined  in  Table 
IV.  It  should  also  be  mentioned  that  in  Table  XII,  the  resource 
utilization  factor  has  been  rounded  off  to  the  nearest  tenth  of  a 
percent  and  is  determined  by  the  following  equation: 

utilization  =  total  claims  *  average  time  per  claim  [6] 
total  clock  time 


84 

89 

Ha 

94 

If  Mess 
99 

i  Deck  < 
104 

Capaci 

109 

ty 

114 

119 

Infinite 

FSA#1 

51.2 

52.2 

52.6 

52.9 

53.2 

53.4 

54.1 

53.8 

53.8 

FSA#2 

46.5 

47.4 

47.7 

48.1 

48.3 

48.5 

49.1 

48.9 

48.9 

FSA#3 

11.2 

11.4 

11.5 

11.5 

11.6 

11.6 

11.8 

11.7 

11.7 

FSA#4 

50.7 

52.3 

53.3 

53.6 

53.4 

53.6 

54.3 

53.3 

53.3 

MS#2 

33.8 

33.6 

33.9 

34.4 

34.0 

35.6 

35.0 

35.0 

35.0 

Table  XII.  Resource  Utilization  Rates  In  Percent 

Except  for  an  occasional  small  deviation,  the  support 
personnel  utilization  rates  presented  in  Table  XII  behaved  as 
expected,  increasing  as  the  mess  deck  capacity,  and  therefore 
serving  line  throughput,  increased,  and  the  overall  process  flow  or 
simulation  run  time  decreased.  It  should  also  be  noted  that  the 
highest  utilization  rate  for  the  FSA  support  personnel  occurred  at  a 
mess  deck  seating  capacity  of  114  seats.  This  is  as  expected  since, 
as  previously  discussed,  the  interaction  between  all  of  the 
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processes  being  modeled  in  the  simulation  was  the  most  efficient 
under  this  mess  deck  seating  condition. 

Mess  Line  Simulation  Conclusions 

Based  on  the  results  of  the  simulation  runs  many 
conclusions  can  be  drawn  on  the  modeled  galley  mess  line  design. 
The  first  is  that  increasing  the  number  of  seats  has  a  minimal  effect 
on  reducing  the  overall  serving  and  messing  time.  Secondly,  the 
mess  deck  seating  capacity  does  have  a  large  effect  on  the  mess 
deck  wait  time  imposed  by  the  mess  deck  master  at  arms  when  all 
mess  deck  seats  are  occupied.  These  conclusions  are  supported  by 
the  data  shown  in  Table  X. 

Other  conclusions  (based  on  the  assumptions  used)  that 
can  be  drawn  to  demonstrate  the  utility  of  the  model  include: 

•  The  length  of  time  required  to  serve  and  feed  the  entire  crew 
and  troop  complement  with  both  the  port  and  starboard  serving 
lines  is  approximately: 

—  2  hours  and  32  minutes  for  the  baseline  design  mess  deck 
capacity  of  168  seats 

—  2  hours  and  24  minutes  for  a  mess  deck  with  infinite  seating 
capacity 

•  The  combined  overall  average  serving  line  flow  rate  based  on 
serving  the  entire  complement  of  crew  and  troops  using  both 
serving  lines  is: 

—  8.0  people  per  minute  for  the  baseline  design  mess  deck 
capacity  of  168  seats 

—  8.4  people  per  minute  for  a  mess  deck  with  infinite  seating 
capacity 

•  The  number  of  people  that  can  be  served  in  the  first  twenty-one 
minutes  from  both  serving  lines  is: 

—  170  people  for  the  baseline  design  mess  deck  capacity  of  168 
seats 

—  228  people  for  a  mess  deck  with  infinite  seating  capacity 

•  At  an  11  to  12  percent  utilization  rate,  the  FSA  responsible  for 
hotwell  restocking  is  a  good  candidate  for  manning  reduction 
assuming  no  additional  duties  than  those  modeled  are  actually 
assigned  to  this  person. 

•  At  a  50.7  to  53.3  percent  utilization  rate  for  one  serving  line, 
the  scullery  FSA  is  a  good  candidate  for  a  manning  increase 
assuming  that  this  person  is  solely  responsible  for  restocking  the 
utensil  dispensers  in  both  the  starboard  and  port  serving  lines. 

•  The  serving  and  messing  time  performance  curves  indicate  that 
the  interaction  between  the  serving  line  and  the  mess  deck  is 
most  efficient  at  a  mess  deck  seating  capacity  of  228  seats. 

The  modeled  results  also  indicate  that  the  baseline 
serving  line  may  be  over  designed  for  the  actual  environment  in 
which  it  will  operate.  As  identified  above,  the  maximum 
throughput  that  can  be  obtained  for  the  current  design,  as  modeled 
with  a  mess  deck  capacity  of  168,  is  170  crew  and  troop  members 
in  the  first  21  minutes.  This  raises  several  questions  concerning 
the  serving  line  design  as  modeled.  These  questions  include: 

•  Might  less  capable  and  less  expensive  serving  line  equipment 
result  in  a  throughput  more  commensurate  with  that  imposed 
by  the  mess  deck  seating  capacity  constraint? 


•  Can  the  Mess  Deck  Master  At  Arms  duties  and  responsibilities 
be  eliminated  if  the  serving  line  was  designed  with  a  throughput 
matching  that  imposed  by  the  mess  deck  seating  capacity 
constraint,  and  therefore  allowing  a  constant  flow  of  personnel 
into  the  mess  deck?  This  is  a  possible  manning  reduction 
opportunity. 

The  most  important  conclusion  is  that  the  time  required 
to  serve  and  feed  the  crew  and  troops  can  be  significantly  reduced 
only  by  addressing  both  the  mess 

deck  seating  capacity  constraint  and  the  serving  line  design  and 
process  interactions  together. 

It  is  again  emphasized,  however,  that  the  results 
obtained  and  conclusions  mentioned  above  are  based  on  input  data 
assumptions  that  were  judged  to  be  reasonable.  The  specific 
purpose  of  this  pilot  program  was  to  demonstrate  the  utility  of 
process  flow  simulation  tools. 

VISUALIZATION  TECHNOLOGY 

Virtual  Ship  Production 

This  portion  of  the  paper  summarizes  the  work 
performed  using  visualization  technology  to  simulate  the 
production  process  of  a  hypothetical  amphibious  class  ship.  To 
assist  in  this  effort  a  detailed  master  construction  schedule  of  the 
ship  was  developed  using  the  LX  Preliminary  Design  (PD)  Generic 
Build  Strategy  Study  as  a  reference.  The  production  process  was 
modeled  by  scheduling  the  ship’s  identified  blocks  through  the 
fabrication,  assembly,  and  erection  phases  of  construction. 
Linkages  from  the  schedule  to  the  visualization  tool  were 
developed  to  enable  the  schedule  to  drive  the  visualization 
sequence  for  the  erection  phase.  Certain  long  lead  material  items 
are  also  included  in  the  schedule  and,  therefore,  are  part  of  the 
visualization. 

In  order  to  keep  the  task  generic  in  nature,  a  series  of 
twelve  staging  areas  are  used  to  queue  blocks  after  completion  of 
assembly  and  prior  to  erection.  The  visualization  illustrates  the 
erection  process  from  the  staging  area  forward  to  final  ship 
completion.  The  screen  templates  track  the  elapsed  time  in  weeks 
for  an  easy  to  gage  real  time  status  of  the  ship  construction 
process.  Various  other  useful  templates  are  available  to  customize 
the  software. 

The  results  of  the  task  provide  a  good  first  step  in  the 
evaluation  of  the  early  stage  design/producibility  interface.  The 
visualization  methodology  used  can  be  developed  as  a  shipyard 
specific  tool  to  evaluate  ship  acquisition  proposals,  and  for  project 
management  of  the  acquisition  process.  Because  the  methodology 
used  can  be  customized  and  expanded  upstream  into  the  total 
construction  process,  the  scheduling/visualization  integration 
capability  of  the  shipyard’s  various  processes  is  unlimited. 
Another  unique  aspect  of  this  task  is  that  the  whole  process  is 
Personal  Computer  (PC)  based  with  reasonably  priced 
commercially  available  software  products.  This  allows  the  concept 
to  be  used  without  special  hardware  or  major  software  investment. 
Also,  as  an  early  stage  design  tool,  this  process  is  easily  conveyed 
on  a  network  setup  to  management,  systems  engineers,  technical 
leaders,  and  ship  designers.  This  concept  also  allows  for 
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evaluations  early  on  in  the  design  process  and  at  the  early  stage  of 
the  contract  design  phase. 

The  block  break  configuration  was  developed  by 
importing  CAD  files  from  the  ship  computer  model.  Because  of 
this,  it  is  easy  to  develop  and  simulate  alternate  build  strategies, 
and  visually  evaluate  engineering  changes  and  their  affects  on  the 
producibility  of  the  ship.  The  data  produced  will  also  allow  the  use 
of  “what  if’  scenarios  to  evaluate  schedule  alternatives  and  ship 
construction  sequences,  and  provide  the  ability  to  play  the  actual 
erection  sequence  out  as  a  visualization. 

Every  effort  was  made  in  the  development  process  to 
keep  the  process  as  simple  as  possible  and  user  friendly.  Also,  an 
objective  was  to  have  the  programs  run  on  available  hardware 
configurations  without  major  added  cost  to  the  end  user. 

Software  Selection 

The  software  products  selected  for  use  in  the 
development  of  the  project’s  Virtual  Ship  Production  product 
are  as  follows:  Microsoft  Access  Version  2.0,  Microsoft  Project 
Version  4.0,  Autodesk  3D  Studio  Release  4.0,  and  Microsoft 
Visual  Basic  Version  4.0.  The  criteria  used  in  choosing  these 
products  included  platform  portability,  cost,  performance,  and  data 
exchange  capability.  Microsoft  Visual  Basic  was  selected  as  the 
programming  language  with  which  the  links  and  interfaces 
between  each  of  these  products  were  built. 

Database  Software.  The  selected  software  was  chosen 
to  support  the  database  requirements  of  the  project  because  of  the 
product’s  following  four  characteristics: 

•  It  has  become  a  leading  PC  based  relational  database  software. 

•  It  provides  a  smooth  data  pipeline  between  itself  and  the  chosen 
project  scheduling  software. 

•  It  has  an  exceptional  report  generator. 

•  It  possesses  a  common  programming  language  with  the  other 
software  products. 

In  addition  to  the  above  four  characteristics,  the  software 
was  also  chosen  because  it  and  the  project  scheduling  software 
have  mutual  import/export  capabilities.  This  can  be  done  in  a 
native  file  format  as  well  as  several  intermediate  format  styles. 
The  native  file  capability  means  that  project  scheduling  software 
can  write  directly  to  the  database  software  and  then  read  back  the 
data  into  a  project  file. 

The  report  writer  associated  with  the  database  software 
uses  the  powerful  capabilities  of  query  by  example,  multiple  data 
sources,  and  a  wide  range  of  data  formatting  and  conversion 
functions.  All  of  this  along  with  cross-tab  and  free  form  report 
formats  makes  the  database  report  generator  a  logical  choice  for 
this  project. 

Project  Scheduling  Software.  The  project  scheduling 
software  was  selected  as  the  project  management  software  for  the 
following  reasons: 

•  Affordable  to  second  tier  shipyards; 

•  Pert  network  capability; 

•  Common  data  structure; 


•  Common  programming  language;  and 

•  Interfacing/Object  linking  and  embedding  (OLE)  capability 
with  the  other  software  products. 

Visualization  Software.  The  visualization  software 
product  for  this  project  was  chosen  because  of  the  following 
product  capabilities. 

•  COTS  software. 

•  PC  compatibility. 

•  Capability  of  providing  an  animation  sequence  that  could  be 
viewed  on  the  operator’ s  PC. 

•  3 -Dimensional  graphic  environment  to  adequately  show  ship’s 
block  break  arrangement  and  assembly/build  strategy  sequence. 

•  Capability  of  interfacing  with  scheduling  and  database 
management  programs  in  order  to  accurately  represent  the 
positioning  and  sequence  of  the  identified  ship  blocks  during 
the  “virtual”  construction,  assembly,  and  erection  phases. 

•  “Keyframing”  programming  language  that  allows  easy  control 
of  animation  by  reading,  line  by  line,  an  ASCII  datafile  output 
from  another  program.  Direct  input  of  movement  information 
into  the  3-D  model  environment  is  thereby  performed. 

•  Command  line  rendering  capability,  which  allows  for  easy 
access  and  processing  from  within  another  user  interface,  or 
shell  program. 

•  Single  frame,  and  range  of  frames,  rendering  capability  which 
allows  the  user  to  quickly  render  and  view  any  particular 
moment  in  the  animation  sequence  without  having  to  render 
the  entire  sequence.  This  saves  on  rendering  time.  (Note: 
Rendering  is  the  process  whereby  the  visualization  software 
creates  the  graphical  image  being  portrayed.) 

•  High  quality  rendering  modes  include  photo-realistic  still  scene 
rendering,  and  variable  quality  and  size  rendering.  These 
modes  allow  for  the  production  of  single  frame  still  shots  for 
printing  and  display,  as  well  as  for  control  over  the  disk  space 
and  rendering  time  requirements  of  animations.  Flat,  Gouraud, 
Phong,  and  Metal- shading  modes  also  support  any  range  of 
image  resolution,  thereby  giving  the  user  control  over  animation 
output  to  allow  for  any  system  disk  space  or  time  constraint 
consideration. 

•  Network  rendering  options  that  allow  the  distribution  of 
rendering  tasks  to  other  PCs  running  this  software  in  order  to 
reduce  the  overall  rendering  time  of  the  animation  sequence. 

•  Still  images  can  be  saved  as  color  .GIF,  .JPG,  .TGA,  .TIF, 
.BMP,  and  .JPG  picture  file  formats  that  are  widely  used 
throughout  various  PC  graphics  packages  and  software 
applications. 

In  addition  to  these  factors  the  product  was  also  chosen 
because  it  is  a  well  rounded  visualization  software  package  that  is 
used  by  a  broad  range  of  professionals  (i.e.  videographers, 
architects,  engineers,  etc.)  and  has  a  large  product  support  base. 

Integration  Software.  The  integration  software  was 
chosen  for  this  project  for  the  following  reasons: 

•  It  is  a  capable  Windows  application  development  environment, 
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•  It  can  utilize  data  from  many  sources  in  many  formats,  and 

•  It  can  programmatically  process  data. 

With  the  integration  software,  the  developer  can 
organize  and  design  screen-based  forms  that  present  the  data  of  a 
project  in  logical  and  coherent  ways.  Industry  standard  controls 
can  be  used,  such  as  drop  down  lists,  buttons  and  menus.  In  this 
project,  the  integration  software  allowed  the  developers  to  display 
and  deal  with  the  Virtual  Ship  Production  project  data  in  a 
highly  customized,  more  efficient  way. 

The  integration  software  is  capable  of  complete,  broad 
based  data  manipulation.  It  can  read  and  write  data  from 
numerous  sources  and  it  has  extensive  internal  capabilities  for 
formatting  and  converting  data.  In  this  project,  the  integration 
software  is  used  as  a  data  intermediary  that  moves  data  between 
applications,  displays  the  data,  and  processes  it  for  use  in  an 
animation  program. 

The  integration  software  provides  a  rich,  extensible 
programming  language  and  as  such  it  is  used  in  this  project  to 
process  the  data  it  can  reach.  This  processing  includes  converting 
project  data  into  a  sequential  list  of  events,  scheduling  the  list  of 
events  to  follow  a  bin  filling  scheme  utilizing  variable  resources, 
and  generating  the  data  elements  to  record  the  event.  While 
processing,  the  integration  program  checks  for  errors,  keeps 
statistics  on  resource  usage,  and  converts  the  data  format  to  one 
that  can  be  used  by  the  animation  program.  The  information  is 
then  output  to  a  file  that  is  used  as  input  for  the  animation. 

Product  Model  Development 

Platform  Selection.  As  previously  alluded  to  the  goal 
of  this  project  was  to  develop  a  tool  that  offers  the  following 
capabilities/features : 

•  Uses  Simulation  Based  Design  (SBD),  and  High  Performance 
Visualization  (HPV)  technology  to  model  ship  production 
breaks  and  erection  sequence. 

•  Provides  the  capability  of  incorporating  CAD  Library 
information  for  machinery  and  outfit  components,  and 
establishes  linkages  with  production  schedules  such  as  erection 
and  material  ordering  schedules. 

•  Incorporates  engineering  interfaces  which  provide  a  user 
friendly  environment  for  this  effort. 

With  these  overall  goals  of  the  project  tasking  in  mind, 
the  basic  objectives  of  the  project’s  product,  Virtual  Ship 
Production,  were  further  refined.  As  a  result  it  was  determined 
that  the  end  product  should  provide  the  following  features  and 
capabilities: 

•  Presentations  for  progress  reviews. 

•  Product  platform  portability  (i.e.  PC  based  with  COTS 
software). 

•  Progress  tracking  with  color  presentations  for  shipyard  internal 
use. 

•  Process  lane  resource  planning,  and  throughput/bottleneck 
identification. 


•  Internal  management  presentations  for  “what  if  s”  at  the  vice 
president  level  and  higher. 

•  Detail  tracking  of  completion  at  the  workstation  or  gate  level 
with  process  lane/work  station  simulations. 

•  An  animated  demonstration  of  the  erection  sequence  for 
production  planners,  superintendents  and  foremen  as  a  training 
tool. 

•  Interactivity  allowing  the  user  to  modify  the  schedule  to  reflect 
problems  or  changes  that  occur  during  the  ship  construction 
period  and  identify  the  corresponding  results  that  occur. 

•  A  production  schedule  that  links  the  fabrication,  assembly,  and 

erection  of  the  ship’s  blocks  with  the  ordering, 

inspection/preparation,  and  landing  of  equipment,  and  other 
important  milestones. 

•  The  ability  for  the  user  to  evaluate  different  production 
schedules  and  choose  the  one  that  best  fits  his  or  her 
requirements  (i.e.  optimum  construction  time,  finance 
requirements,  work  load  leveling,  etc.). 

Master  Construction  Schedule  Development.  The 

development  of  a  detailed  master  construction  schedule  was 
accomplished  with  the  above  mentioned  features  and  capabilities 
of  the  finished  product  Virtual  Ship  Production  in  mind.  As 
mentioned  the  information  contained  within  the  LX  Preliminary 
Design  (PD)  Generic  Build  Strategy  Study  was  used  as  a  reference. 
Specific  items  of  interest  contained  within  this  study  included: 

•  Block  Break  Plan 

•  Key  Event  Schedule 

•  Master  Construction  Schedule 

•  Hull  Erection  Schedule 

•  Typical  Long  Lead  Time  (LLT)  Schedule 

•  Typical  LLT  items 

•  A  preliminary  Master  Equipment  List  (MEL) 

The  Master  Construction  Schedule  created  for  the 
project  therefore  was  in  a  large  part  based  upon  the  information 
contained  within  the  LX  Preliminary  Design  (PD)  Generic  Build 
Strategy  Study.  The  work  done  in  developing  the  new  Master 
Construction  Schedule  was  initiated  on  project  scheduling 
software,  and  later  transferred  to  the  database  software  via  the 
front-end  interface  developed  for  this  project. 

Identification  Of  Tasks/Events.  Many  resources  were 
utilized  in  identifying  the  tasks  or  events  that  would  be  tracked  by 
the  new  Master  Construction  Schedule.  In  addition  to  the 
information  contained  within  the  LX  Preliminary  Design  (PD) 
Generic  Build  Strategy  Study ,  historical  ship  construction 
information  was  used  as  well  as  the  shipyard  experience  of  some 
of  the  project  team  members  was  used. 

Based  on  the  information  culled  from  these  sources  it 
was  decided  that  as  a  minimum  the  Master  Construction  Schedule 
would  be  centered  around  the  following  production  processes,  or 
areas  of  concern: 

•  Ship  Construction  Milestones 

•  Hull  Construction 
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•  Outfitting 

These  areas  of  concern,  or  production  processes,  can  be 
further  broken  down  into  sub-elements  as  identified  in  Table  XIII. 


Milestones 

Hull  Construction 

Outfitting  -  Equipment 

-  Contract  Award 

-  Detail  Design 

-  Start  Construction 

-  Lay  Keel 

-  Launch 

-  Builders  Trials 

-  Delivery 

-  Fabrication 

-  Assembly 

-  Erection 

-  Ordering 

-  Receipt,  Inspection,  &  Preparation 

-  Landing 

Note:  The  above  subdivisions  can  be  further  classified  by: 

-  Zone 

-  Sub-Zone 

-  Block 

Table  XIII.  Minimum  Contents  Of  A  Master  Construction 
Schedule 

Milestone/Miscellaneous  Events.  A  number  of 
milestones  and  miscellaneous  events  are  involved  in  scheduling 
and  managing  a  ship  construction  process.  Although  all  of  these 
events  should  be  used  in  developing  a  ship’s  Generic  Build 
Strategy  and  overall  production  schedule,  only  ten  of  them  are 
identified  and  visually  displayed  by  the  project’s  associated 
graphics  package.  These  ten  events  are  identified  below: 


•  Contract  Award 

•  Detail  Design 

•  Start  Construction 

•  Lay  Keel 

•  Start  Superstructure  Erection 


•  Launch 

•  Dock  Trials 

•  Builders  Trials 

•  Acceptance  Trials 

•  Delivery 


These  events  were  chosen  for  the  following  reasons: 


•  The  nature  of  the  event  lends  itself  to  being  easily  shown  during 
the  visualization  of  the  ship  production  process; 

•  The  scheduling  and  completion  of  the  event,  or  task,  greatly 
effects  the  overall  production  process; 

•  The  event,  or  task,  can  be  easily  used  to  gauge  the  progress  of 
production;  and 

•  There  is  a  distinct  start,  stop,  or  time  period  associated  with  the 
task,  or  event. 

Hull  Construction.  The  shipbuilding  process  currently 
utilized  by  modem  shipyards  is  based  upon  the  principle  of  Group 
Technology  (GT).  In  addition  to  being  a  philosophy  of  grouping 
products  based  on  similar  production  characteristics,  GT  is  also 
used  as  an  umbrella  which  covers  a  number  of  other  production 
methods.  The  Hull  Block  Construction  Method  (HBCM),  used 
during  the  stmctural  constmction  of  ships,  is  one  of  the  methods 
which  falls  within  the  domain  of  GT.  In  HBCM,  ship  stmctures 
are  incrementally  built  up  from  interim  products  until  the  final 
product,  a  ship’s  stmcture,  is  achieved.  Depending  upon  the 
design,  and  the  production  capabilities  of  the  shipyard,  this  method 
of  ship  constmction  can  employ  up  to  seven  different 
manufacturing  levels.  These  levels  are  characterized  primarily  by 
the  stage  of  production  in  which  they  are  found,  and  can  also  be 
further  classified  into  three  groups  based  on  their  predominant 
production  aspects. 


For  the  purposes  of  this  project  though,  the  work  flow 
path  was  modeled  as  consisting  of  the  following  four  basic  steps: 

•  Block  Fabrication 

•  Block  Assembly 

•  Crane  Transfer 

•  Block  Erection 

There  were  a  number  of  reasons  for  this  reduction  in  the 
detail  of  the  HBCM  work  flow  path,  including  the  fact  that  it  is  the 
Block,  and  not  necessarily  the  interim  products  (i.e.  semi-block 
assembly,  sub-block  assembly,  part  assembly,  and  part  fabrication), 
that  is  the  key  stmctural  element  in  the  constmction  of  a  ship.  In 
other  words,  the  ship’s  Block  Breakdown,  and  the  resultant 
production  aspects  of  each  Block,  determine  the  work  flow  that 
will  be  experienced  during  the  ship’s  constmction  process.  Other 
reasons  for  minimizing  the  amount  of  detail  concerning  the  ship 
constmction  process  that  is  tracked  and  visually  presented  in  this 
project  include: 

•  The  Master  Constmction  Schedule  contained  within  the  ship’s 
Preliminary  Build  Strategy  identified  the  stmctural  start  and 
stop  events  associated  only  with  block  fabrication,  assembly, 
and  erection. 

•  Shipyard  Master  Constmction  Schedules  normally  track  only 
the  following  stmctural  events:  block  erection,  block  assembly, 
and  block  fabrication.  (Note:  Sometimes  these  latter  two  events 
are  tracked  as  a  single  event.) 

•  The  three  events  tracked  are  directly  germane  to  the  erection  of 
the  ship 

The  crane  transfer  task  has  been  added  to  the  revised 
HBCM  work  flow  path  in  order  to  represent  the  transfer  by  crane 
of  the  blocks  from  the  staging  area  to  the  erection  site. 

For  this  project  the  hypothetical  ship’s  hull  constmction 
process  is  modeled  as  consisting  of  184  blocks.  Each  of  these 
blocks  will  be  individually  identified  and  tracked  by  the  project’s 
product  model. 

Outfitting.  The  outfitting  process  in  ship  production  is 
an  extremely  complicated  one  that  can  also,  if  not  properly 
managed,  be  very  time  extensive.  Like  HBCM,  there  is  also  an 
outfitting  method  specifically  associated  with  Group  Technology. 
This  method,  called  the  Zone  Outfitting  Method  (ZOFM), 
incorporates  the  same  principals  and  philosophies  of  Group 
Technology  that  HBCM  does.  In  ZOFM,  the  outfitting  process  is 
broken  down  into  a  sequence  of  steps  that  indicate  the  process 
taken  in  landing  equipment  aboard  ship.  There  are  six  different 
stages,  or  manufacturing  levels  associated  with  the  Zone  Outfitting 
Method. 

As  with  HBCM,  the  outfitting  process  being  modeled  in 
this  project  is  an  abbreviated  form  of  ZOFM.  Unlike  the  original 
process,  which  contains  six  different  manufacturing  levels,  the 
revised  outfitting  method  only  identifies  three  manufacturing 
levels.  These  levels  are  identified  in  Table  XIV,  and  are  meant  to 
only  identify  the  major  process  associated  with  placing  equipment 
onboard  the  ship  and  not  describe  the  entire  process  in  detail.  This 
reduction  in  the  amount  of  detail  being  represented  was  done  in 
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order  to  develop  a  management  tool  that  contains  a  similar  level  of 
detail  to  that  normally  associated  with  the  upper  management  level 
in  a  ship  construction  program. 


Outfitting  Level  - 
Equipment 

Description 

Ordering 

Point  of  time  at  which  the  item  is  ordered. 

Receipt, 

Inspection,  and 
Preparation  (RIP) 

Span  of  time  covering  the  processes  associated 
with  the  item’s  receipt,  inspection,  and 
preparation  for  landing  in  the  block  or  ship. 

Landing 

Process  of  actually  placing  the  item  in  the 
block  or  ship. 

Table  XIV.  Outfitting  Manufacturing  Levels  Modeled 

For  the  purposes  of  this  project,  it  was  decided  to  model 
only  the  outfitting  process  associated  with  some  of  the  ship’s 
critical  equipment  and/or  long  lead  time  (LLT)  items.  The  selected 
items,  and  the  blocks  with  which  they  are  associated  are  identified 
in  Table  XV. 

The  relationship  that  the  critical  equipment/LLT  items 
being  modeled  in  this  project  have  with  the  phase  of  ship 
construction  in  which  they  are  landed  is  identified  in  Table  XV.  In 
this  table  the  After  Block  Erection  phrase  signifies  on-board 
outfitting,  and  indicates  that  the  landing  of  the  item  can  not  occur 
until  after  the  erection  of  the  block  in  which  it  will  be  placed  has 
been  completed.  Likewise,  the  phrase  During  Block  Assembly 
indicates  that  the  item  will  be  landed  or  joined  with  the  block 
during  the  block’s  assembly  phase;  it  represents  on-block 
outfitting.  Not  shown  in  this  Table,  and  therefore  not  tracked  by 
the  project  model,  are  the  first  two  stages  of  assembly  as  identified 
by  ZOFM.  Theses  stages,  On  Unit  Outfitting  or  Unit  Assembly 
and  Grand  Unit  or  Grand-Unit  Joining ,  are  associated  with  the 
process  of  joining  a  component  to  another  component  which  will 
eventually  be  landed  either  in  a  block  or  on-board  the  ship.  An 
example  of  this  is  a  controller  for  a  fire  pump  module;  it  is  joined, 
with  some  other  equipment,  to  a  firepump,  but  not  directly  to  the 
block  or  the  ship.  It  is  the  module  that  is  actually  joined,  and 
therefore  it  is  the  module  and  its  associated  manufacturing 
processes  that  are  tracked  by  a  ship  construction  program’s  upper 
management. 


Equipment 

Associated 

Block 

Ship  Construction 
Landing  Phase 

Main  Engine 

3102 

After  Block  Erection 

Reduction  Gear 

3102 

After  Block  Erection 

Main  Engine 

3402 

After  Block  Erection 

Reduction  Gear 

3402 

After  Block  Erection 

SSDG 

2201 

After  Block  Erection 

SSDG 

2202 

After  Block  Erection 

SSDG 

3202 

After  Block  Erection 

SSDG 

3501 

After  Block  Erection 

SSDG 

3502 

After  Block  Erection 

Switch  Board 

2221 

After  Block  Erection 

Switch  Board 

2222 

After  Block  Erection 

(2)  Switch  Boards 

3221 

After  Block  Erection 

Switch  Board 

3521 

After  Block  Erection 

Switch  Board 

3522 

After  Block  Erection 

Steering  Gear 

4421 

During  Block  Assembly 

Steering  Gear 

4422 

During  Block  Assembly 

Table  XV.  Equipment  Landing  and  Associated  Ship 
Manufacturing  Level 

Identification  Of  Event  Interdependencies  Or 
Linkages.  In  addition  to  identifying  the  events  that  will  be 
tracked,  the  dependencies  or  linkages  between  them  also  need  to 
be  identified  in  order  to  develop  a  model  that  accurately  portrays 
the  shipbuilding  process.  These  dependencies  and  linkages  cover  a 
wide  range  of  focus  that  includes  both  the  general  sequencing  of 
the  events,  and  the  delays  inherent  in  progressing  from  one  event 
to  the  next. 

For  this  project,  the  linkages  between  each 
event  were  modeled  as  closely  as  possible  to  the  actual  linkages 
that  occur  in  a  shipyard.  A  simple  example  of 
this  is  some  of  the  dependencies  that  were  developed  for  the 
outfitting  process.  As  already  mentioned,  the  outfitting  process  is 
represented  in  the  project’s  product,  Virtual  Ship  Production,  as 
three  simple  and  basic  events:  Equipment  Ordering,  Equipment 
RIP,  and  Equipment  Landing.  The  dependencies  that  were 
developed  to  help  realistically  portray  this  sequence  are  listed 
below. 

•  Equipment  ordering  occurs  prior  to  equipment  RIP. 

•  Equipment  RIP  occurs  prior  to  equipment  landing. 

•  Equipment  landing  can  not  occur  until  after  the  appropriate 
block  is  ready  to  receive  it  (i.e.  depending  on  the  equipment 
either  after  block  erection  or  during  block  assembly). 

•  There  is  a  one  day  delay  imposed  prior  to  the  start  of  the  next 
sequential  event  (i.e.  if  RIP  for  a  specific  equipment  concludes 
on  Monday,  the  landing  of  that  equipment  can  not  start  until 
Tuesday). 

•  The  baseline  timespan  between  ordering  equipment  and 
receiving  is  commensurate  with  the  procurement  lead  time 
required  for  ordering  that  equipment. 

•  A  crane  is  required  to  be  available  in  order  to  transport  the 
equipment  from  the  equipment  staging  area  to  the  area  in 
which  it  will  be  landed. 
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•  Construction  of  the  block  is  not  completed  until  all  components 
are  installed. 

•  If  the  equipment  is  to  be  installed  on  board  then  it  will  be 
landed  prior  to  the  block’s  covering  (i.e.  through  open  air). 

Similar  dependencies  were  also  created  and  imposed  on 
the  ship’s  structural  construction  processes  as  identified  by  the 
project’s  product  model,  Virtual  Ship  Production  (i.e.  Block 
Fabrication,  Block  Assembly,  and  Block  Erection). 

In  addition  to  these  dependencies,  inter-block 
dependencies,  or  linkages,  were  also  developed  for  the  erection 
sequence  in  order  to  ensure  that  any  proposed  Hull  Erection 
Schedule  accurately  portrayed  and  incorporated  the  sequencing 
prerequisites  that  shipyards  are  subjected  to.  These  inter-block 
dependencies  are  identified  in  the  following  list,  and  are  applicable 
to  the  majority  of  blocks  associated  with  a  ship. 

•  Erect  from  the  mid-body  area  outwards. 

•  Inner  blocks  are  erected  prior  to  wing  wall  blocks. 

•  Blocks  are  not  covered  until  all  appropriate  equipment  that 
needs  to  be  joined  to  them  at  the  erection  site  are  landed  (for 
this  project  see  Table  XVI). 

•  Erection  of  a  block  on  top  of  another  requires  that  the  lower 
block,  and  adjacent  lower  blocks  within  the  same  ‘Unit’  are 
already  erected. 

•  Sufficient  time  is  provided  for  the  fitting  and  welding  of  blocks 
prior  to  landing  new  blocks  over  them. 

In  short,  the  above  mentioned  dependencies  are  rules 
that  in  most  cases  closely  resemble  the  ‘rules  of  thumb’  utilized  by 
shipyard  planners.  How  close  these  ‘rules  of  thumb’  are  adhered 
to  is  dependent  on  the  specific  design  aspects  of  the  ship  being 
erected.  For  this  project,  these  rules  form  the  cornerstone  around 
which  any  proposed  erection  schedule  will  be  built.  As  such,  they 
have  been  entered,  where  applicable,  as  predecessors  to  each  event 
in  the  ship’s  production  schedule,  and  should  not  be  over-ridden 
except  by  the  program  manager,  or  his  or  her  representative,  in 
order  to  ensure  model  integrity. 

Software  Product  Interface 

The  next  few  subsections  describe  the  user  interface  of 
the  Virtual  Ship  Production  product,  and  some  of  the  interface’s 
special  features.  These  special  features  include  the  ability  to  apply 
cost  figures  to  the  tasks  being  tracked,  as  well  as  being  able  to 
apply  both  the  Ship  Work  Breakdown  Structure  (SWBS)  and 
Product  Work  Breakdown  Structure  (PWBS)  classification  system 
to  them. 

Data  Entry  Templates.  The  main,  or  first,  template  of 
the  Virtual  Ship  Production  product  is  shown  in  Figure  3.  The 
discussion  and  screen  prints  that  follow  this  figure  describe  the 
user  interface,  or  templates,  of  the  product  Virtual  Ship 
Production. 

Clicking  on  the  Data  Tool  button,  Figure  4,  will  bring  up 
the  Virtual  Data  form.  This  form  is  used  to  view  and  edit  data  that 
is  specific  to  the  ship  building  schedule.  The  data  that  is  available 
on  the  Virtual  Data  form  is  more  detailed  than  that  which  is 
generally  available  in  the  project  schedule  file.  Any  schedule  data 


that  is  edited  on  this  form  is  transferred  back  to  the  project 
schedule  file  thereby  changing  it.  Any  non- schedule  data  that  is 
added  or  edited  will  also  be  stored  with  the  project  schedule  file. 

The  Virtual  Data  form,  Figure  5,  is  comprised  of  two 
main  areas.  The  filter  area  allows  the  user  to  narrow  the  scope  of 
task  events  that  can  be  viewed.  The  tabbed  folder  displays  the 
actual  project  data. 

The  filter  area  has  three  option  buttons  and  a  drop  down 
list.  The  option  buttons  determine  what  type  of  task  events  to 
show  in  the  drop  down  list.  One  can 


Figure  3.  Virtual  Ship  Production  Master  Template 


Figure  4.  VSP  Data  Tool  Button 


Figure  5.  VSP  Virtual  Data  Form 

select  either  milestone,  equipment,  or  block  tasks  to  be  listed  on 

the  drop  down  list.  From  the  drop  down  list  a 

particular  item  can  be  picked  and  the  data  viewed  on  the  tab  folder. 

The  tabbed  folder  has  four  tabs  across  the  top  that  break 
out  the  details  of  the  project  data.  These  tabs  are  titled  Schedule, 
Sequence,  References,  and  Resting  Point. 

The  Schedule  tab,  Figure  6,  contains  a  table  grid  that 
displays  some  of  the  basic  data  items  from  the  project.  The  table 
grid  is  divided  into  seven  columns.  Each  column  has  a  self 
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explanatory  heading  identifying  the  type  of  data  contained  within 
it.  The  seven  column  headings  are: 

•  Task  ID  •  Duration 

•  Task  •  Duration  Source 

•  Start  •  Resources 

•  Stop 


Figure  6.  VSP  Schedule  Tab 

The  Sequence  tab,  Figure  7,  displays  the  data  relevant  to 
the  task’s  position  or  sequence  within  the  project  schedule. 
Included  on  this  tab  are  columns  that  display  the  task’s  predecessor 
and  successor  information.  A  column  for  miscellaneous 
information  is  also  included. 


Figure  7.  VSP  Sequence  Tab 

The  Reference  tab,  Figure  8,  lists  the  tasks  related  to  the 
filter  selection  and  any  background  or  referral  information.  The 
columns  of  data  displayed  are: 

•  Task 

•  POC  (Point  Of  Contact) 

•  Phone 

•  Task  ID 

•  Cost 

•  PWBS  (Product  Work  Breakdown  Structure) 


•  SWBS  (Ship  Work  Breakdown  Structure) 


Figure  8.  VSP  Reference  Tab 

The  Resting  Point  tab,  Figure  9,  provides  both  a  visual 
and  coordinate  display  of  where  the  ship’s  blocks  will  be  landed  at 
the  erection  site.  The  resting  points  can  be  shown  by  individual 
block  or  by  a  group  of  blocks.  For  an  individual  block,  the  Filter 
section  above  the  tabbed  folder  can  be  used  to  select  the  block  of 
interest.  The  type  of  groups  can  be  selected  either  by  zone  or  for 
the  entire  ship.  The  display  of  zone  resting  points  is  done  by 
clicking  the  mouse  over  a  particular  zone.  All  resting  points  and 
their  coordinates  relating  to  that  zone  will  then  be  shown  on  the  list 
box. 


Figure  9.  VSP  Resting  Point  Tab 

If  the  user  is  not  familiar  with  the  applicable  zones,  the 
Show  Zones  check  box,  Figure  10,  can  be  clicked  and  the  zones 
will  be  overlaid  on  the  ship  diagram.  The  XYZ  position  of  the 
item’s  resting  point  can  be  edited  as  required.  Clicking  the  Add 
Point  button  will  create  a  new  resting  point  for  the  user  to  enter  the 
appropriate  coordinates  for. 
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Figure  10.  Show  Zones  Check  Box 

The  Virtual  Ship  Production  product  also  provides 
controls  that  allow  the  user,  or  VSP  system  administrator,  to 
change  some  of  the  low  level  settings  that  affect  the  look  and  feel 
of  the  visual  rendering.  The  controls  for  these  settings  are 
accessed  by  clicking  on  the  Settings  tool  button  on  the  Main  Form, 
Figure  11.  Doing  so  brings  up  the  Setting  Central  form. 


Figure  11.  VSP  Settings  Tool  Button 

The  Setting  Central  form  is  a  tabbed  form  that 
segregates  the  different  classes  of  data.  The  tabs  are  Areas,  Queue, 
Week  and  Deltas. 

The  Areas  tab  allows  the  administrator  to  modify  or  add 
staging  areas.  Editing  is  done  in  typical  word  processing  fashion 
by  highlighting  the  value  to  be  changed  and  using  cursor  keys  to 
delete  or  change  the  entry.  Adding  a  value  is  done  by  moving  the 
cursor  to  a  blank  row  and  typing  in  the  values. 

The  Queue  tab  is  very  much  like  the  Areas  tab  in  that  it 
displays  the  names  and  coordinates  of  the  queue  positions.  Editing 
and  adding  values  for  the  queues  is  also  done  in  the  same  manner 
as  the  Areas  tab. 

The  Week  tab  allows  the  administrator  to  alter  the 
positions  and  set  the  timing  of  the  ‘week  buttons.’  The  following 
data  entry  points  are  provided  for  each  position  (i.e.  in  and  out):  X 
position,  Y  position,  Z  position,  and  Timing. 

The  Deltas  tab  is  where  the  system  administrator  is  able 
to  fine  tune  the  rendering  process  of  the  Virtual  Ship  Production 
system.  The  five  sub-areas  are: 

•  Hoist  Point  •  Hide  Point 

•  Time  Deltas  •  Abbreviate  Milestones 

•  Miscellaneous  Deltas 

The  Hoist  Point  sub-area  is  where  the  coordinates  of  the 
crane  hoist  point  is  set.  In  addition  to  the  X-Y-Z  values,  the  timing 
or  duration  of  the  hoist  event  is  entered  in  this  sub-area. 


The  Time  Deltas  area  is  where  the  delay  frame  values 
for  the  following  events  are  entered:  leave,  elevate,  center  point, 
final,  reschedule.  These  events  are  described  in  Table  XVI. 


Event 

Description 

Leave 

The  number  of  days  a  block  or  piece  of 
equipment  is  delayed  before  being  elevated  out 
of  the  staging  area. 

Elevate 

The  difference  between  ‘elevate’  and  ‘leave’  is 
the  time  (in  days)  required  for  a  block  or  piece  of 
equipment  to  move  from  the  staging  area  to  the 
elevate  point. 

Center  Point 

The  difference  between  ‘center  point’  and 
‘elevate’  is  the  time  (in  days)  required  for  a  block 
or  piece  of  equipment  to  move  from  the  elevate 
point  to  the  center  point. 

Final 

The  difference  between  ‘final’  and  ‘center  point’ 
is  the  time  (in  days)  required  for  a  block  or  piece 
of  equipment  to  move  from  the  center  point  to  its 
final  resting  point  at  the  erection  site  (or,  for 
certain  equipment,  the  assembly  building). 

Reschedule 

The  minimum  number  of  days  the  schedule  for 
lifting  a  block  or  piece  of  equipment  from  the 
staging  area  is  delayed  due  to  a  scheduling 
conflict. 

Table  XVI.  Time  Delta  Events 


The  Miscellaneous  deltas  apply  to  other  various 
functions  in  the  rendering  process.  They  are  identified  in  Table 
XVII. 


Function 

Description 

Milestone  Time 

The  duration,  in  frames,  of  a  milestone  show  event. 

Elevate  Height 

The  height  in  coordinate  values  to  elevate  an  item 
above  the  staging  area. 

Hour/Frame 

The  number  of  hours  per  frame  represented  by  the 
rendering. 

Frame  Default 

The  number  of  frames  used  if  no  other  delta 
applies. 

Reserved 

Open  for  future  enhancements. 

Table  XVII.  Miscellaneous  Deltas 

The  Hide  Point  sub  area  is  where  the  coordinates  for  the 
hide  point  are  entered.  The  Hide  point  is  where  blocks  or  pieces  of 
equipment  are  pre-staged  out  of  view  in  the  rendering,  just  before 
they  are  moved  to  a  staging  area.  The  timing  text  box  is  where  the 
time  value  or  delay,  by  frame,  for  pre- staging  is  set. 

The  Abbreviate  Milestones  check  box  is  used  to  set 
whether  a  fixed  period  of  time  is  used  for  milestones  or  whether 
their  actual  time  of  duration  is  used.  This  feature  is  generally  used 
when  there  are  numerous  milestones  that  precede  any  building 
activity.  When  checked,  the  milestones  will  be  shown  at  fixed 
periods,  according  to  the  milestone  timing  set,  instead  of  their 
relative  time  and  thus  shortening  the  inactive  period  of  the 
rendering  (i.e.  the  period  during  which  construction  activities  are 
not  visually  being  displayed). 
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Element  Classification  And  Cost  Entry  Data  Points. 

In  order  to  accommodate  the  functionality  offered  by  the  Product 
Work  Breakdown  Structure  (PWBS)  and  Ship  Work  Breakdown 
Structure  (SWBS)  classification  system,  as  well  as  the  potential 
linkage  of  data  between  this  project’s  product  and  the  Product 
Oriented  Design  and  Construction  (PODAC)  Cost  Estimating 
Model  currently  under  development,  a  PWBS,  SWBS  and  cost 
data  entry  point  for  each  event  tracked  by  the  product  model  is 
included  in  the  ‘Virtual  Data  -  References’  template.  The  direct 
importance  on  the  project’s  product  of  these  entry  points  is  that 
they  provide  the  ability  to  track  costs  by  their  associated  products 
and  events  in  a  time  or  calendar  format.  This  will  allow  the  user  to 
create  prospective  expenditure  schedules  and  graphs,  as  well  as 
comparative  (actual  versus  proposed)  ones. 

The  exact  code  that  will  be  used  to  identify  each 
individual  type  of  product  in  accordance  with  the  PWBS 
breakdown  structure  is  currently  being  developed  under  the  Mid 
Term  Sealift  Ship  Technology  Development  Program.  The  coding 
used  for  the  SWBS  data  entry  point,  on  the  other  hand,  is  in 
accordance  with  the  current  NAVSEA  SWBS  coding  system. 

Visualization  Model 

The  shipyard  depicted  during  the  visualization  process 
of  the  ship  construction  program  is  a  generic  shipyard  that  shows 
the  minimum  amount  of  information  required  to  visually  convey 
the  merits  of  the  viewed  ship  construction  program.  As  such  it 
contains  one  dry  dock,  twelve  block  staging  areas,  six  equipment 
staging  areas,  a  block  queuing  area,  an  equipment  queuing  area, 
and  an  assembly  building.  In  addition  to  these  items  a  stainless 
steel  colored  placard  is  located  at  the  top  of  the  screen  over  the 
shipyard.  Upon  this  placard  the  ten  milestones  and  miscellaneous 
events  from  the  ship’s  Master  Construction  Schedule,  as  identified 
in  the  paragraph  titled  Milestones/Miscellaneous,  are  displayed  as 
they  occur.  Each  one  is  depicted  as  a  raised,  stainless  steel  colored 
button  with  black  lettering. 

The  model’s  clock  is  also  displayed  on  the  placard  in 
addition  to  the  ten  buttons.  It  is  located  at  the  bottom  right  hand 
comer  and  consists  of  two  buttons;  one  labeled  ‘Week’,  and  the 
other  the  appropriate  numerical  symbol  (i.e.  1,  2,  3,  etc.). 
Although  visually  the  time  is  progressing  by  two  hour  intervals,  the 
time  units  associated  with  an  event  can  also  be  adjusted  by  the  user 
through  the  Virtual  Ship  Production  interface. 

The  block  staging  area  contains  a  maximum  of  12  lots 
that  can  be  utilized  by  the  ship  production  program.  The  exact 
number  that  will  be  used  is  dependent  on  the  shipyard  that  is  being 
modeled,  and  requires  input  by  the  user.  Although  the  lots  remain 
on  the  screen  during  the  visualization  process  when  they  are  not 
used,  they  are  also  not  loaded  with  blocks.  In  this  way  they  can  be 
thought  of  as  resources,  for  they  are  used  only  when  available,  and 
the  actual  number  available  does  affect  the  outcome  of  the  ship 
production  program. 

Associated  with  each  staging  area  is  a  queue  line,  or 
area.  These  queues  are  included  in  the  product  model’s 
visualization  process  in  order  to  help  convey  the  merits,  or  pitfalls, 
associated  with  the  Master  Constmction  Schedule  being  displayed. 
Along  with  the  staging  area  lots,  they  can  be  used  for  visually 
determining  if  a  production  plan  undemtilized  a  shipyard’s 
resources,  or  over  utilizes  them.  If  the  latter  is  occurring  then 


work  in  process  (WIP)  is  also  occurring.  This  is  seen  when  the 
lots  associated  with  the  queuing  area  begin  to  be  loaded  with 
blocks,  or  equipment,  waiting  to  arrive  at  the  staging  area.  A  good 
example  would  be  when  the  schedule  indicates  that  there  are  16 
blocks  in  the  staging  area.  In  this  case,  all  twelve  lots  are  being 
used,  and  there  will  also  be  four  blocks  shown  in  the  queuing  area. 
Under  utilization  of  the  shipyard  resources,  on  the  other  hand,  can 
be  seen  when  the  available  lots  in  the  staging  areas  are  never  fully 
utilized  (i.e.  there  is  always  at  least  one  lot  that  is  empty).  Another 
way  to  determine  these  characteristics  of  a  constmction  plan  is 
through  the  report  option  available  in  the  project  schedule  and 
database  software.  Although  not  as  visually  appealing,  reports 
using  this  option  are  able  to  deliver  much  more  detailed 
information. 

The  assembly  building  is  included  in  the  visual  display 
of  the  shipyard  to  show  where  some  of  the  equipment  might  go 
after  arriving  in  the  shipyard.  A  good  example  of  this  is  the 
steering  gear.  At  the  conclusion  of  the  RIP  process,  as  determined 
by  the  Master  Constmction  Schedule,  each  gear  is  shown  visually 
arriving  in  the  equipment  staging  area  and  then  traveling  and 
disappearing  into  the  assembly  building.  In  this  way  they  are 
visually  shown  as  being  joined  to  the  block  during  its  assembly 
phase  instead  of  landed  in  the  block  after  it  has  been  erected. 

The  specific  start/stop  dates  for  the  element  moves  (i.e. 
blocks  and  equipment)  identified  in  the  visualization  sequence 
were  determined  by  utilizing  certain  task  start  and  stop  dates  as 
determined  by  the  project  schedule  file.  The  specific  tasks  and 
date  identifiers  utilized  are  listed  in  Table  XVIII. 


Task  or 
Event 

Date  Identifier 
Utilized 

Visualization  Movement 
Relationship 

Block 

Assembly 

Actual  End 
Date 

Arrival  of  the  Block  in  the 
Block  Staging  Area 

Block 

Erection 

Actual  Start 

Date 

Departure  of  the  Block  from 
the  Block  Staging  Area 

Equipment 

RIP 

Actual  Start 

Date 

Arrival  of  Equipment  in  the 
Equipment  Staging  Area 

Equipment 

Landing 

Actual  Start 

Date 

Departure  of  Equipment  from 
the  Equipment  Staging  Area 

Table  XVIII.  Material  Flow  Determination  Criteria 

A  snap  shot  of  a  demonstration  mn  of  the  Virtual  Ship 
Production  product  is  shown  in  Figure  12.  This  snap  shot  is 
taken  from  a  camera  angle  on  the  stem  of  the  ship  looking  forward 
instead  of  the  default  position  off  the  starboard  side  looking 
inboard.  This  change  in  camera  position  was  made  to  demonstrate 
the  flexibility  of  the  visualization  software’s  rendering  process.  By 
specifying  the  XYZ  coordinates  for  the  camera  in  the  rendering 
process  setup,  the  user  can  easily  change  the  view  of  the  ship 
constmction  process  being  displayed  to  suit  particular  needs. 
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Figure  12.  Stern  View  Of  Ship  Construction 
Block  Break  Visualization.  During  the  project,  the 
visualization  software  was  also  used  to  view  and  print  the 
graphical  images  of  the  equipment  and  individual  blocks;  the  latter 
was  also  viewed  by  sub-zone  in  an  exploded  and  unexploded 
format.  This  capability  was  found  to  be  very  useful  in  helping  to 
verify  the  block  break  descriptions.  Some  samples  of  this 
capability  are  provided  in  Figures  13  and  14.  Labels  have  been 
attached  to  the  blocks  in  these  figures  in  order  to  help  identify 
them. 


3501  3502 


Figure  13.  Exploded  View  Of  Sub-Zone  3500 


Figure  14.  Solid  View  Of  Sub-Zone  3500 


Special  Options 

In  order  to  provide  user  functionality  to  the  Virtual 
Ship  Production  product  a  couple  of  special  options  were  also 
created  or  designed  into  the  product.  These  options  include  tools 
and/or  capabilities  in  the  following  two  areas:  task  filtering  and  risk 
assessment. 

Task  Filtering.  An  important  feature  of  any  scheduling 
or  management  tool  is  its  ability  to  filter  information  as  required  or 
needed.  This  is  especially  true  when  managing  large  projects  like 
ship  construction,  where  many  types,  or  groups  of  information  are 
often  placed  together  in  a  single  schedule,  report,  or  file. 

In  this  project,  the  ship  construction  project  file  contains 
both  task  and  resource  related  information.  These  two  classes  of 
information  type  can  be  further  divided  into  numerous  sub-classes 
each  of  which  tracks  a  specific  aspect  of  the  applicable  ship 
production  program.  In  order  to  assist  the  program  manager  in  the 
retrieval  of  this  information,  a  number  of  filters  were  added  to  the 
default  list  provided  by  the  project  scheduling  software.  These 
additional  filters  were  created  by  using  the  filter  editing  capabilities 
of  the  project  scheduling  software  and  entering  the  relevant 
information  in  the  appropriate  project  file  data  columns.  A  brief 
description  of  each  of  these  additional  filters  is  provided  in  Table 
XIX. 

Risk  Assessment.  Although  schedules  do  aid  in  the 
organization  and  management  process  of  any  project,  they  are  not 
necessarily  accurate.  Because  the  information  entered  into  a 
schedule  is  only  as  accurate  as  its  source  is  able  to  make  it,  the 
information  received  from  a  schedule  is  rarely  if  ever  one  hundred 
percent  accurate.  This  is  especially  true  for  the  dates  and  durations 
of  the  events  being  tracked  within  a  schedule.  Quite  often  these 
factors  are  guesses  and  estimates  based  on  past  performance,  or 
the  actual  past  performances  of  similar  processes.  They  are  not 
guaranteed.  In  light  of  this,  the  capability  of  creating  schedules 
based  on  statistical  distributions  is  highly  desired.  When  this  is 
done,  and  a  number  of  iterations  are  accomplished,  a  risk 
assessment  of  the  schedule  is  performed.  The  result  is  a 
compilation  of  schedules  ranging  from  the  most  probable  to  the 
least  probable,  and  a  number  of  possible  critical  paths. 
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In  order  to  allow  the  user  to  be  able  to  add  this 
functionality  to  his  or  her  management  project,  Virtual  Ship 
Production  has  been  organized  in  a  manner  that  allows  the 
incorporation  of  a  couple  of  different  risk  analysis  systems.  These 
systems  provide  project  management  functionality  that  allows  the 
user  to  assign  statistical  distributions  to  selected  task  events  and 
event  duration.  With  this  capability  the  user  is  able  to  perform  a 
number  of  iterations  on  the  schedule  in  question,  and  determine 
the  most  to  least  likely  schedule  scenarios,  project  duration,  critical 
paths,  and  critical  path  tasks. 


Filter  Name 

Filter  Description 

Block 

Show  all  tasks  associated  with  the  specified 
block  number. 

Filter  Out 
Process/Stage 

Show  all  tasks  that  are  not  associated  with  the 
specified  process  or  stage. 

Process/Stage 
and  Block 

Show  the  task  that  contains  this  specified 
process  or  stage  for  the  identified  block  number. 

Process/Stage  & 
Zonal/Unit  Range 

Show  the  tasks  that  contain  this  specified 
process  or  stage  for  the  identified  range  of  zones 
or  units. 

Process/Stage 

Show  all  tasks  associated  with  the  specified 
process/stage. 

Zonal/Unit  Range 

Show  all  tasks  associated  with  the  specified 
range  of  zones  or  units. 

Table  XIX.  Filters 
Resource  Load  Leveling 

In  addition  to  the  above  mentioned  special  options,  the 
project  scheduling  software  also  offers  three  methods  of 
determining  project  durations.  These  methods  are  fixed-duration 
scheduling,  resource-driven  scheduling,  and  a  combination  of  the 
two.  Fixed-duration  scheduling  is  strictly  time  based  using  task 
durations  that  are  interlinked  with  the  scheduled  task  start  and  stop 
dates.  In  resource-driven  scheduling,  however,  the  task  durations 
are  based  on  the  work  content  of  the  task  and  the  amount  of 
resources  assigned  to  it.  When  a  combination  of  these  methods  is 
used  some  of  the  task  durations  are  determined  by  one  method, 
while  the  remaining  task  durations  are  determined  by  the  other 
method. 

As  indicated  above,  the  application  of  resource-driven 
scheduling  allows  a  project  schedule  to  be  tailored  to  fit  the  actual 
resources  available  for  performing  the  assigned  tasks.  This 
capability  of  the  project  scheduling  software  lends  itself  well  to  the 
scheduling  and  analysis  features  of  the  Virtual  Ship  Production 
product.  Through  the  application  of  resource-driven  scheduling, 
ship  production  schedules  can  be  analyzed  with  regards  to  the 
specific  capabilities  of  a  shipyard.  When  resources  are  applied  to 
tasks  at  a  degree  greater  than  their  capacity,  however,  resource 
load  leveling  conflicts  occur.  Fortunately,  the  project  scheduling 
software  is  able  to  identify  when  this  happens,  and  immediately 
notifies  the  user.  The  user,  or  project  manager  can  then  manually, 
or  with  the  assistance  of  the  options  provided  within  the  project 
scheduling  software,  resolve  the  conflict  by  leveling  the  resources, 
and  thereby  adjusting  the  schedule. 

In  using  the  Virtual  Ship  Production  product  it  is 
recommended  that  at  a  minimum  resource-driven  scheduling  be 


applied  to  the  crane  transfer  tasks.  The  utilization  of  this  capability 
on  this  event  will  not  only  help  to  identify  where  resource  load 
leveling  conflicts  occur,  but  also  as  a  minimum  produce  a  schedule 
that  is  representative  of  a  shipyard’s  crane  capacity  for  landing 
blocks  and  equipment  at  the  erection  site. 

Visualization  Technology  Conclusions 

The  visualization  process  developed  for  the  Virtual 
Ship  Production  product  is  a  tool  that  can  be  used  by  all  levels  of 
the  shipyard  management  team  and  program  acquisition  team. 
The  Ship  Acquisition  Program  Manager  (SHAPM)  can  use  this 
tool  to  manage  the  project,  to  monitor  progress,  evaluate 
construction  scenarios  and  generally  keep  Integrated  Product  and 
Process  Development  (IPPD)  teams  completely  abreast  of  the 
latest  construction  process  as  the  ship  acquisition  process  takes 
place.  This  schedule/visualization  tool  is  also  useful  for  high  level 
presentations  at  NAVSEA  or  command  level  briefings. 

Other  specific  areas  in  which  computer  visualization  can 
be  used  as  a  tool  in  shipbuilding  include: 

•  Linkages  to  shipyard  detail  schedules: 

(a)  Engineering  plan  schedule 

(b)  Outfitting 

—  Pallet  schedule 

—  Long  Lead  Time  Material  (LLTM)  schedule 
—  Shop  schedules  -  Marshaling  yard 

(c)  Hull  steel  unit  schedules 
—  Shop 

-  Platen 

—  Gate/work  station 

(d)  Erection  schedule 

—  Grand  units/Blocks 
—  Shipway 

(e)  Zones  -  on  ship 

—  Zone  outfitting  schedules 

•  Present  new  production  sequences  to  show  rescheduling 
influences 

•  Progress  tracking  with  color  presentations  for  shipyard  internal 
use 

•  Training  tool  for  production  planners,  superintendents  and 
foremen 

•  Process  lane  resource  planning,  and  throughput/bottle  neck 
identification 

•  Training  tool  that  provides  an  animated  demonstration  of  the 
erection  sequence 

•  Progress  presentations,  and  expected  progress  presentations,  for 
government  Quarterly  Progress  Reviews  (QPR’ s) 

•  Internal  management  presentations  to  do  “what  ifs”  at  the  vice 
president  level  and  higher 

•  Detail  tracking  of  completion  at  the  work  station  or  gate  level 
with  process  lane/work  station  simulations 

•  Gate  presentation  for  supervision  showing  the  manner  in  which 
the  unit  will  be  sitting  for  welding  and  for  outfitting  in  their 
gates 
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CONCLUSIONS 

Many  conclusions  can  be  drawn  from  the  previous 
sections.  The  basic  premise  of  these  conclusions  though  should  be 
that  if  utilized  properly,  simulation  based  design,  and  visualization 
technology,  offer  an  extremely  high  return  on  investment.  With  a 
very  wide  scope  of  application,  from  the  production  planning 
function  and  the  planning  efforts  through  to  the  vice  presidential 
level  for  high  level  presentations,  these  two  technologies  are  an  aid 
to  all  levels  of  the  shipyard  management  team. 

A  specific  area  in  which  these  techniques  would  be 
helpful  to  a  shipyard  is  in  the  development  of  their  build  strategy. 
This  is  because  the  build  strategy  includes  within  it  a  sequence  of 
erection  which  in  turn  influences  all  of  the  upstream  production 
department  involvement  and  scheduling  decisions.  A  ship’s  build 
strategy  and  resultant  sequence  of  erection  therefore  are  strongly 
influenced  by  the  various  aspects  of  the  shipyard  environment. 
These  aspects  include  the  building  and  erection  site  availability,  as 
well  as  material  availability,  and  concerns  in  the  level  loading  of 
human  resources  and  cash  flow.  It  is  with  these  problems  and 
concerns  in  mind,  that  visualization  and  the  benefits  of  computer 
simulation  aides  are  considered  most  helpful  in  the  planning 
process. 

As  indicated,  both  simulation  based  design  and  process 
flow  simulation  are  wonderful  tools  for  design  and  analysis 
purposes.  When  utilized  properly  they  offer  the  opportunity  to 
analyze  design  decisions  for  bottlenecks  and  inefficiencies  early  in 
the  design  cycle  where  changes  and  modifications  can  still  be 
made.  This  capability  allows  the  design  team  to  produce  an 
optimized,  or  highly  efficient  design,  with  a  high  degree  of 
confidence.  Another  benefit  of  these  design  techniques  is  that 
when  a  design  is  selected  for  use  its  performance  characteristics 
will  be  known.  Modifications  or  improvements  to  existing  designs 
can  also  be  analyzed  for  their  effectiveness  through  the  application 
of  process  flow  analysis.  The  only  drawback  with  this  technique 
of  design  and  analysis  is  that  its  results  are  only  as  accurate  as  the 
data  used  to  develop  the  simulation  model. 

Unfortunately,  if  these  processes  are  applied  late  in  the 
design  process,  such  as  near  the  completion  of  the  contract  design 
stage,  the  implementation  of  any  modifications  to  the  design  based 
on  the  results  of  these  studies  is  remote.  Any  and  all  suggested 
modifications  to  the  design  would  have  to  be  carefully  evaluated; 
weighing  the  benefits  of  the  modification(s)  against  the  cost  impact 
of  implementing  them.  Because  of  this,  it  is  recommended  that  in 
all  future  ship  design  programs  process  flow  design  and  analysis 
methods  be  applied  as  early  as  possible  in  the  ship  design  process 
in  order  to  obtain  the  maximum  benefits  offered  by  this  technique. 
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